Under consideration for publication in Theory and Practice of Logic Programming 1 



Logical Algorithms meets CHR 

A M eta- Complexity Result for Constraint Handling Rules with Rule Priorities 

Leslie De Koninck 

Department of Computer Science, K.U.Leuven, Belgium 
(e-mail: Fi rs tName . L as tName <Scs. kuleuven .be) 

submitted 20 December 2007; revised 20 December 2008; accepted 9 January 2009 



Abstract 

This paper investigates the relationship between the Logical Algorithms language (LA) of 
Ganzinger and McAllester and Constraint Handling Rules (CHR) . We present a translation 
schema from LA to CHR rp : CHR with rule priorities, and show that the meta-complexity 
theorem for LA can be applied to a subset of CHR rp via inverse translation. Inspired by the 
high-level implementation proposal for Logical Algorithm by Ganzinger and McAllester 
and based on a new scheduling algorithm, we propose an alternative implementation for 
CHR rp that gives strong complexity guarantees and results in a new and accurate meta- 
complexity theorem for CHR rp . It is furthermore shown that the translation from Logical 
Algorithms to CHR rp combined with the new CHR lp implementation, satisfies the required 
complexity for the Logical Algorithms meta-complexity result to hold. 

KEYWORDS: Constraint Handling Rules, Logical Algorithms, complexity analysis. 



1 Introduction 

Constraint Handling Rules (CHR) (Fruhwirt h 1998[) is a high-level rule based lan- 
guage, originally designed for the implementation of constraint solvers, but also 
increasingly used as a general purpose programming language. Recently, it was 
shown that all algorithms can be implemented in CHR while preserving both time 
and space complexity (Sneyers et al. 2005). We assume some familiarity with CHR 



and refer to (Friih wirth 1998P for more details. 

In "Logical Algorithms" (LA) (Ganzinger and McAlleste r 2002[ ) (and based on 



previous work in ( Ganzinger and McAllester 2001 [McAlleste r 1999|0 . Ganzinger 



and McAllester present a bottom-up logic programming language for the pur- 
pose of facilitating the derivation of complexity results of algorithms described 
by logical inference rules. This problem is far from trivial because the runtime 
is not necessarily proportional to the derivation length (i.e., the number of rule 
applications), but also includes the cost of pattern matching for multi- headed 
rules, as well as the costs related to high-level execution control which is spec- 
ified using rule priorities in the Logical Algorithms language. The language of 
Ganzinger and McAllester resembles CHR in many ways and has often been referred 
to in the discussion of complexity results of CHR programs (Christiansen 2005; 
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IFriihwirth 2002b! |Schrijvers and Friihwirth 2006| |Sneyers et al. 2006a[). In partic- 



ular, in (Christiansen 2005), Christiansen uses the meta-complcxity theorem that 
accompanies the Logical Algorithms language, and notes that the CHR system used 
(SICStus CHR by Holzbaur et al. (IHolzbaur and F riihwirth 1998j) ) does not always 
exhibit the right complexity because previously computed partial rule matches are 
not stored. 

The aim of this paper is to investigate the relationship between both languages. 
More precisely, we look at how the meta-complexity theorem for Logical Algo- 
rithms can be applied to (a subset of) CHR, and how CHR can be used to imple- 
ment Logical Algorithms with the correct complexity. First, we present a transla- 
tion schema from Logical Algorithms to CHR rp : CHR extended with rule priorities 
(|De Koninck et al. 2007b|) . Logical Algorithms derivations of the original program 
correspond to CHR rp derivations in the translation and vice versa. We also show 
how to translate a subclass of CHR rp programs into Logical Algorithms. This al- 
lows us to apply the meta-complexity theorem for Logical Algorithms to these 
CHR rp programs as well. Because the Logical Algorithms meta-complexity theo- 
rem is based on an optimized implementation, it gives more accurate results than 
the implementation independent meta-complcxity theorem of (jFriihwirth 2 002a; 
Friihwirth 2002b) while being more general than the ad-hoc complexity derivations 
in ( |Schrijvers and Friihwirth 200 6; Sncyc rset al. 2006a] ). 

Our current implementation of CHR rp as presented in (|De Koninck et a"I~2 008) 
does not guarantee the complexity required for the meta-complexity theorem for 
Logical Algorithms to hold via translation to CHR rp . Another issue is that the 
translation from CHR rp to Logical Algorithms is restricted to a subset of CHR rp . 
Therefore, we propose a new implementation of CHR rp , designed such that it sup- 
ports a new meta-complexity theorem for the complete CHR rp language, while also 
ensuring that Logical Algorithms programs translated into CHR rp are executed 
with the correct complexity. 

The implementation is based on the high-level implementation proposal for Logi- 



cal Algorithms as given in ( Ganzinger and McAllester 2002 ), and on a new schedul- 



ing data structure proposed in (|De Koninck 2007)) . By using a CHR system with ad- 
vanced indexing support, such as the K.U.Leuven CHR system (Schrijvers and Demoen 2004 ) 



our implementation achieves the complexity required to enable a new and accurate 
meta-complexity result for the whole CHR rp language. 



Overview The rest of this paper is organized as follows. In Section [2j the syntax 
and semantics of the Logical Algorithms language and CHR rp are reviewed and the 
known meta-complexity theorems for both languages are presented. In Section [3] a 
translation of LA programs to CHR rp programs is presented and in Section 21 the 
opposite is done for a subset of CHR rp . Section [5] proposes an alternative implemen- 
tation for CHR rp which enables a new meta-complexity theorem for this language, 
given in Section [6] Some concluding remarks are given in Section [Jj 
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2 Logical Algorithms and CHR rp 

In this section, we give an overview of the syntax and semantics of Logical Al- 
gorithms (Section 12. ip and CHR rp (Section 12. 2[) . In Section [2.31 we review the 
meta-complexity results that are known for both languages. 

2.1 Logical Algorithms 

This subsection gives an overview of the syntax and semantics of the Logical Algo- 
rithms language. 

2.1.1 Syntax 

A Logical Algorithms program P = {7*1, . . . , r n } is a set of rules. In flGanzinge r and McAllester 2002[ ), 
a graphical notation is used to represent rules. We use a new textual representation 
that is closer to the syntax of CHR. A Logical Algorithms rule is an expression 

r@p:A 1 ,...,A n ^C 

where r is the rule name, the atoms Ai (for 1 < i < n) are the antecedents and 
C is the conclusion, which is a conjunction of atoms whose variables appear in 
the antecedents. Rule r has priority p where p is an arithmetic expression whose 
variables (if any) occur in the first antecedent A\. If p contains variables, then 
r is called a dynamic priority rule. Otherwise, it is called a static priority rule. 
In the graphical notation of (Ganzinger and McAllester 2002), the above rule is 
represented as shown below. 

A 1 



0>p) — 
c 

The arguments of an atom are either Herbrand terms or (integer) arithmetic ex- 
pressions. There are two types of atoms: comparisons and user-defined atoms. A 
comparison has the form x<y, x<y,x — yorx^y with x and y arithmetic 
expressions or, in case of (=)/2 and (^)/2, Herbrand terms. Comparisons are only 
allowed in the antecedents of a rule and all variables in a comparison must appear 
in earlier antecedents. A user-defined atom can be positive or negative. A negative 
user-defined atom has the form del(A) where A is a positive user-defined atom. A 
ground user-defined atom is called an assertion. 

Example 1 

An example rule (from Dijkstra's shortest path algorithm as presented in ( |Ganzinger and McAllester 2002D ) 
with name d2 and priority 1 is 

d2 1 : dist(V,Di), dist(V,D 2 ), D 2 < Di => del (dist (V,Di ) ) . 
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The antecedent D 2 < Di is a comparison, the atoms dist(V,Di) and dist(V,D 2 ) 
arc positive user-defined antecedents. The negative ground atom del (dist (a, 5) ) 
is an example of a negative assertion. 

2.1.2 Operational Semantics 

A Logical Algorithms state a consists of a set of (positive and negative) assertions. A 
state can simultaneously contain the positive assertion A and the negative assertion 
del(A). In the rest of this paper, we sometimes use the word database as a synonym 
for a LA execution state. Let T> be the usual interpretation for the comparisons. 
Given a program P, the following transition converts one state into the next: 



1. Apply a > — > p (j U 9(C) if there exists a (renamed apart) rule r in P of 
priority p of the form 

r @p: Ax,...,A n ^C 
and a ground substitution 9 such that for every antecedent Ai, 

• T> \= 6(Ai) if Ai is a comparison 

• 0(Ai) G o~ and del(9(Ai)) ^ a if A,; is a positive user-defined atom 

• 0(Ai) G a if Ai is a negative user-defined atom 

Furthermore, 9(C) ^ cr and no rule of priority p' and substitution 9' exists 
with 9'(p') < 9(p) for which the above conditions hold. 

A state is called final if no more transitions apply to it. A non-final state has priority 
p if the next firing rule instance has priority p. The condition 9(C) ^ a ensures 
that no rule instance fires more than once and prevents trivial non-termination. This 
condition, combined with the fact that each transition only creates new assertions, 
causes the consecutive states in a derivation to be monotone increasing. Although 
the priorities restrict the possible derivations, the choice of which rule instance to 
fire from those with equal priority is non-deterministic. 

2.2 CHR rp : CHR with Rule Priorities 

CHR rp is CHR extended with user-definable rule priorities. It is introduced in 
(|De Koninck et al. 2007b|) as a solution to the lack of high-level execution control 
in CHR. In this section, we review the syntax and semantics of CHR rp . 

2.2.1 Syntax 

A constraint c(ti, . . . , t n ) is an atom of predicate c/n with t^ a host language value 
(e.g., a Herbrand term in Prolog) for 1 < i < n. There are two types of constraints: 
built-in constraints and CHR constraints (also called user-defined constraints). The 
CHR constraints are solved by the CHR program whereas the built-in constraints 
are solved by an underlying constraint solver (e.g., the Prolog unification algorithm). 



Logical Algorithms meets Constraint Handling Rules 



5 



There are three types of Constraint Handling Rules: simplification rules, propa- 
gation rules and simpagation rules. They have the following form: 

Simplification p :: r @ H r <==> g | B 

Propagation p :: r @ H k ==>■ g \ B 

Simpagation p :: r @ H k \ H r g \ B 

where p is the rule priority, r is the rule name, H k and H r are non-empty sequences 
of CHR constraints and are called the heads of the rule. The rule guard g is a 
sequence of built-in constraints and the rule body B is a sequence of both CHR and 
built-in constraints. The rule priority is either a number in which case the rule is 
called a static priority rule, or an arithmetic expression whose variables appear in 
the heads H k and/or H r in which case the rule is called a dynamic priority rule. We 
say that priority p is higher than priority p' if p < p' . For simplicity, we sometimes 
assume priorities are integers and the highest priority is 1. Finally, a program P is 
a set of CHR rules. Apart from the rule priorities, CHR rp is identical to CHR. 

2.2.2 Operational Semantics 

Operationally, CHR constraints have a multi-set semantics. To distinguish between 
different occurrences of syntactically equal constraints, CHR constraints are ex- 
tended with a unique identifier. An identified CHR constraint is denoted by c^i 
with c a CHR constraint and i the identifier. We write chr(c#«) = c and id(c#i) = i 
and pointwise extend these functions to sets and sequences of constraints. 

The operational semantics of CHR rp , called the priority semantics and denoted 
by u p , is given in (|De Koninck et al. 2007bj) as a state transition system, similar 
to the approach of (jDuck et al. 2004"j) for the theoretical and refined operational 
semantics of CHR. A CHR execution state a is represented as a tuple (G, S, B, T) n 
where G is the goal, a multi-set of constraints to be solved; S is the CHR constraint 
store, a set of identified CHR constraints; B is the built-in store, a conjunction of 
built-in constraints; T is the propagation history, a set of tuples denoting the rule 
instances that have already fired; and n is the next free identifier, used to identify 
new CHR constraints. The transitions of lj p are shown in Table Q] where T> denotes 
the built-in constraint theory and 3xY denotes the existential closure of Y apart 
from the variables in X. The transitions are exhaustively applied starting from the 
state {G,$,true,$)i with G the initial goal. We have used the simpagation rule 
form to denote any type of rule in the Apply transition. For simplification rules, 
Hi and H[ are empty, and for propagation rules, Hi and H' 2 are empty. 

The following theorem on the correspondence between the oj p semantics of CHR rp 
and the theoretical operational semantics Lo t of CHR (see e.g. (jDuck et al. 2004} ). 
is proven m (|De Koninck et al. 2007b|) . 

Theorem 1 

Every derivation D under uj p is also a derivation under a;*. If a state a is a final 
state under lu p , then it is also a final state under u>t- 

In the refined operational semantics of CHR (Du ck et al. 2004} . the textual order 
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1. Solve ({c} t+J G, S 1 , B, T) n ►-> p (G, S,cA B, T) n where c is a built-in constraint. 

2. Introduce ({c} l+l G,S,B,T) n ^ P (G, {c#n} U S,B,T) n+ i where c is a CHR 
constraint. 

3. Apply (®,HiL>H 2 US,B,T}n ^>p (0(G), Hi U S,B,TU {t}) n where P contains 
a rule of priority p of the form 

p :: r @ •<=>■ g \ C 

and a matching substitution 9 such that chr(ffi) = 9(H[), chr(_ff2) = ^(i/^), 23 |= 
£> — » 3B0(g); 9(p) is a ground arithmetic expression and t — (r, \d(Hi) ++- \d(H2)) ^ 
T. Furthermore, no rule of priority p' and substitution 9' exists with 9'(j>') < 9(p) 
for which the above conditions hold. 

Table 1 . Transitions of u> v 



of the program rules determines which rule is tried next for the current active 
constraint. However, only rule instances in which the active constraint takes part 
are considered, and so a higher priority fireable rule instance in which the active 
constraint does not participate, will not fire. The textual rule order also does not 
support dynamic rule priorities. 



2.2.3 Differences compared to Logical Algorithms 
CHR rp differs from Logical Algorithms in the following ways: 

• A Logical Algorithms state is a set of ground assertions, while the CHR 
constraint store is a multi-set and may also contain non-ground constraints. 

• In Logical Algorithms, built-in constraints are restricted to ask constraints 
and only include comparisons; CHR rp supports any kind of built-in con- 
straints. 

• A removed CHR constraint may be reasserted and can then participate again 
in rule firings whereas a removed LA assertion cannot be asserted again. 

• A Logical Algorithms rule may contain negated heads. In contrast, CHR rp 
requires all heads to be positiveQ 

• In the Logical Algorithms language, the priority of a dynamic priority rule is 
determined by the variables in the left-most head, whereas in CHR rp it may 
depend on multiple heads. 

We note that rules for which the priority depends on more than one head, can easily 
be transformed into the correct form as follows. Given a Logical Algorithms rule of 
the form 

An 



Sec (Van Wccrt ct al. 2006) for an extension of CHR with negation as absence. However, the 
semantics of that form of negation is different from the one in Logical Algorithms. 
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where the priority expression p is fully determined by the variables from the an- 
tecedents A\, . . . ,A m . This rule can be transformed into the equivalent rules 

n @ 1 : A x , . . . , A m priority,, (p) 

r 2 @p: priority r (p), A\, . . . , A m ,A m+1 , ...,A n ^>C 

where priority^/ 1 is a new user-defined predicate. Now the first head of the dynamic 
priority rule determines the rule priority. The above transformation causes the 
creation of priority r /l assertions. We have that every execution state of the trans- 
formed program can be mapped on a corresponding execution state of the original 
program (assuming rule priorities are allowed to depend on multiple heads) by 
removing these priority,,/ 1 assertions. 

2.3 M eta- Complexity Results 

The Logical Algorithms language was designed with a meta-complexity result in 
mind. Such a result has also been formulated for CHR. In this subsection, we review 
both results and give a first intuition on how they relate to each other. 

2.3.1 The Logical Algorithms Meta- Complexity Result 

A prefix instance of a Logical Algorithms rule r @ p : A\, . . . , A n =>■ C is a tuple 
(r, i, 9) with 9 a ground substitution defined on the variables occuring vn A\, . . . , Ai 
and 1 < i < n. Its antecedents are 9{A\), . . . , 9{Ai). A strong prefix firing is a prefix 
instance whose antecedents hold in a state with priority lower or equal to the prefix' 
rule priority. In ( |Ganzinger and M cAllcst er 2002| ), also the concept of a weak prefix 
firing is defined, but it is of no importance for our purposes. The time complexity for 
running Logical Algorithms programs is given in (Ganzinger and McAllcster 2002) 
as O(\a \+P s + (Pd + Ad) ■ log N) where cto is the initial state and \ao | is its size. P s 
is the number of strong prefix firings of static priority rules and Pd is the number of 
strong prefix firings of dynamic priority rules; A<j is the number of assertions that 
may participate in a dynamic priority rule instance; and N is the number of distinct 
priorities. The following example is adapted from ( Ganzinger and McAllester 2002[ ). 



Example 2 (Dijkstra's Shortest Path) 

The rules below implement Dijkstra's single source shortest path algorithm. 



dl C 


3 1 


source (V) => dist(V,0). 


d2 C 


3 1 


dist(V.Di), dist(V,D 2 ), D 2 < Dj => deKdist (V,D a ) ) . 


d3 C 


3 D+2 


dist(V.D), e(V,C,U) => dist (U.D+C) . 



A source ( V) assertion means that V is the (unique) source node for the algorithm. 
A dist ( V, D) assertion means that the shortest path distance from the source node 
to node V does not exceed D. Finally, an e(V ,C ,U) assertion means that there 
is an edge from node V to node U with cost (weight) C. Given an initial state 
consisting of one source/1 assertion and e e/3 assertions, we can derive that the 
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number of strong prefix firings is 0(1) for rule dl, and 0(e) for both rules d2 and 
d3, and so both P s and Pd are 0(e). This result is based on the fact that at priority 
2 and lower (numerically larger), there is at most one (positive) dist/2 assertion 
for each node, and each of these assertions represent the shortest path distance 
from the source node to this node. This means that at most e dist/2 assertions are 
ever created, and Ad = 0(e). Finally, the number of distinct priorities is bounded 
by the number of dist/2 assertions, i.e., N — 0(e). Using the meta-complcxity 
theorem, we find that the total complexity is 0(e + e + (e + e) • log e) = 0(e log e). 



In (jFruhwirth 2002al IFruhwirth 2002bp , an upper bound on the worst case time 
complexity of a CHR program P is given as 



where D is the maximal derivation length (i.e., the maximal number of rule firings), 
Cmax is the maximal number of CHR constraints in the store, and for each rule 
r G P: 

• n r is the number of heads in r 

• Ou r is the cost of head matching, i.e. checking that a given sequence of n r 
constraints match with the n r heads of rule r 

• Oa r is the cost of checking the guard 

• Oc r is the cost of adding built-in constraints after firing 

• Ob,, is the cost of adding and removing CHR constraints after firing 

For programs with simplification and simpagation rules only, the maximal deriva- 
tion length can be derived using an appropriate ranking on constraints that de- 
creases after each rule firing (Friihwirth 2000a) . We note that finding such a ranking 
is not trivial. The meta-complcxity result is based on a naive CHR implementa- 
tion, and therefore on the one hand gives an upper bound on the time complexity 
for any reasonable implementation of CHR, but on the other hand often largely 
overestimates the worst case time complexity on optimized implementations!! The 
following example is adapted from (Friihwirth 2002a). 

Example 3 (Boolean) 

The rules below implement the boolean and(X, Y,X AY) constraint given that 1 
represents true and represents false. 

and(0,Y,Z) <=> Z = 0. and(X,0,Z) <=> Z = 0. 

and(X,l,Z) <=> X = Z. and(l,Y,Z) <=> Y = Z. 

and(X,X,Z) <=> X = Z. and(X,Y,l) <=> X = 1 , Y = 1. 



2 Built-in constraints may lead to a worse complexity in practical optimized implementations if 
many constraints are repeatedly reactivated without this resulting in new rule firings. We return 
to this issue in Section 16.31 



2.3.2 The "As Time Goes By" Approach 




(1) 
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Let the rank of an and/3 constraint be one, then the rank of the head of each rule 
equals one, and the rank of the body equals zero because by definition, all built-in 
constraints have a rank of zero. For a goal consisting of n and/3 constraints, the 
derivation length is n, which is also the maximal number of CHR constraints in 
the store. The cost of head matching, (implicit) guard checking, removing CHR 
constraints and asserting built-in constraints can all be considered constant. Then 
using ([T]), we derive that the total runtime complexity is 0(n 2 ). 



2.3.3 A First Comparison 

Although at this point we do not intend to make a complete comparison between 
both results, we can already show that the Logical Algorithms result in a sense is at 
least as accurate as Fruhwirth's approach, at least as far as programs without built- 
in tell constraints are concerned. The reasoning is as follows. In each derivation step, 
a constant number of atoms (constraints) are asserted. Let c max be the maximal 
number of (strictly) positive assertions in any given state. Furthermore assume rules 
have positive heads only, then each of the asserted atoms can participate in at most 
J2reP ( Ur ' c max) strong prefix firings. Because only 0(c + D) constraints are ever 
asserted where c is the number of CHR constraints in the initial goal and D is the 
derivation length, the total number of strong prefix firings P s + Pd is 



r£P / 



and because c = 0(c max ) we also have the following bound 

oiD-Y^^naA (2) 

\ r£P I 

In absence of (dynamic) priorities, the total runtime complexity according to the 
Logical Algorithms meta-complexity result is bounded by the same formula ((2|) and 
hence is at least as accurate as the result of (lFruhwirth 2002b) given that the cost 
of both head matching {Oh t ) and adding and removing CHR constraints {Ob t ) is 
constant for each rule r. 



3 Translating Logical Algorithms into CHR rp 

In this section, we show how Logical Algorithms programs can be translated into 
CHR rp programs. CHR states of the translated program can be mapped onto LA 
states of the original. With respect to this mapping, both programs have the same 
derivations. 



3.1 The Translation Schema 



The translation of a LA program P is denoted by T(P) = T S/D (P) U T R (P). The 
definitions of T S / D {P) and Tr{P) are given below. 
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3.1.1 Set and Deletion Semantics 

We represent Logical Algorithms assertions as CHR constraints consisting of the 
assertion itself and an extra argument, called the mode indicator, denoting whether 
it is positively asserted ("p"), negatively asserted ("n") or both ("b"). For every 
user-defined predicate a/n occurring in P, T S / D (P) contains the following rules to 
deal with a new positive or negative assertion: 

1 :: a r (X, M) \ a(X) <S=^> M ^ n | true 
1 :: a r (X,n),a(X) <^ a r (X,b) 
2 :: a(X) a r (X,p) 

1 :: a r (X,M) \ del{a{X)) M ± p | true 

1 :: a r (X,p),del(a(X)) ^> a r (X,b) 
2 :: del(a(X)) a r (X,n) 

If a representation already exists, one of the priority 1 rules updates this represen- 
tation. Otherwise, one of the priority 2 rules generates a new representation. At 
lower (numerically larger) priorities, it is guaranteed that every assertion, whether 
asserted positively, negatively or both, is represented by exactly one constraint in 
the store. 



split(L4|T]) 



3.1.2 Rules 

Given a LA rule r E P oi the form 

r @p : A 1 ,...,A n C 

We first split up the antecedents into user-defined antecedents and comparison 
antecedents by using the split function defined below. 

j ([A\A U ], A c ) if A is a user-defined atom 
| (A u , [A\A C ]) if A is a comparison 
where split(T) = (A U ,A C ) 
split(O) =(□,[]> 

In the Logical Algorithms language, a given assertion may participate multiple 
times in the same rule instance, whereas in CHR all constraints in a single rule 
instance must be different. To overcome this semantic difference, a single LA rule 
is translated as a set of CHR rules such that every CHR rule covers a case of 
syntactically equal head constraints. Let (A u , A c ) = split([Ai, . . . , A n ]) with A u = 
[A?, A^] and A c = [A\, . . . , Af]. Let V be the set of all partitions of {1, ... , m}. 
For a given partition p £ V, the following function returns the most general unifier 
that unifies all antecedents {Ai \ i G S} for every S € p where mgu(5') is the most 
general unifier of all elements in £. 

partition_to_mguO, [A?, A^}) = o mgu({^ | i G 5*}) 

6Gp 
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Let VIA = {{p, 9) | pe VA6 = partition_to_mgu(p, A U )AV \= 3 6»(A C )}. VU contains 
all partitions for which partition_to_mgu is defined and for which the comparison 
antecedents A c are still satisfiable after applying the unifier. The next step is to 
filter out antecedents so that every set in the partition has only one representative. 
This is done by computing V\\ter(8(A u ), p) for each (p, 6) <E VIA where the filter 
function is as follows: 



filter([0(^)|T],p) 



modes(L4 u \T\) = ■ 



[6{A?)\mer(T,p)] if3Sep:i = min(S) 
filter(T, p) otherwise 

filter([},_)=\\ 

Finally, we add mode indicators to all remaining user-defined antecedents: 

' '([a r (X,p)\A m ],N) if A u '=a(X) 

{[a r (X,N')\A m ],[N' ^p\N}) if A u ' = del(a(X)) 

where (A m ,N) = modes(T) 
modes(D) =([],[]) 

The modes function returns both the resulting antecedents and the necessary con- 
ditions on the mode indicators of these antecedents. For every (p, 0) £ VIA, the 
CHR translation Tr(-P) contains a rule 

p + 2::r p @H gi ,g 2 | C 

where (H, gi ) = modes(filter(6»(A u ), p)), g 2 = 6(A C ) and C = 6(C). 

3.1.3 Examples 
We illustrate the translation schema on some examples. 
Example 4 

A LA implementation of Dijkstra's shortest path algorithm is 



dl C 


5 1 


source (V) => dist(V,0). 




d2 ( 


5 1 


dist(V,Di) , dist(V,D 2 ) , 


D 2 < Di => deKdistCV.D!)) . 


d3 ( 


3 D+2 


dist(V,D), e(V,C,U) => 


dist(U,D+C) . 



Its translation is 



erCV.C.U.M) \ e(V,C,U) <=> M \= n I true. 
erCV.C.U.n) , e(V,C,U) <=> e r (V,C,U,b). 

e(V,C,U) <=> e r (V,C,U,p) . 

e r (V,C,U,M) \ del(e(V,C,U)) <=> M \= p I true. 
e r (V,C,U,p) , del(e(V,C,U)) <=> e r (V,C,U,b). 

del(e(V,C,U)) <=> e r (V,C,U,n). 



. . '/, (similar rules for source/1 and dist/2) 
3 : : dli source r (V,p) ==> dist(V.O). 
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3 :: d2 1/2 @ dist r (V,Di ,p) , dist r (V,D 2 ,p) ==> D 2 < Di I del(dist(V,Di)) . 
D+4 :: d3 1/2 @ dist r (V,D,p) , e r (V,C,U,p) ==> dist(U,D+C) . 



Example 5 

A rule from the union-find implementation of ( Ganzinger and McAllester 2002 1 is 
the following: 



uf4 1 : union(X,Y), find(X,Z), find(Y.Z) => del(union(X,Y) ) . 



Because antecedents find(X,Z) and find(Y,Z) are unifiable, this leads to the 
following two CHR rules: 



3 :: uf4 1/2/3 <3 union r (X,Y,p) , f ind r (X,Z,p) , find r (Y,Z,p) ==> del (union (X, Y) ) . 
3 :: uf4 1/23 @ union r (X,X,p) , f ind r (X,Z ,p) ==> del (union (X , X) ) . 



3.2 The Correspondence between LA and CHR 113 Derivations 

In this subsection, we show that every derivation of the original program under 
the Logical Algorithms semantics, corresponds to a derivation of the translation 
under the uj p semantics of CHR rp . In order to do so, we introduce a mapping 
function chr_to_la between reachable CHR execution states and Logical Algorithms 
states; see (|Duck et al. 2007")) for a formal definition of reachability. Reachability is 
considered with respect to initial states of the form (G, 0, true, 0)„ where the user- 
defined constraints in G are of the form a(X) and del{a{X)) and do not include 
constraints of the form a r (X,M). 

chr_to_la(cr) = {a(X) \ a{X) £ A V (a r [X, M) £ A A M ^ n)} 

U {del(a(X)) \ del{a{X)) £ A V (a r (X, M) £ A A M p)} 

where a = {G,S,B,T) n and A — G U chr(S). The mapping function also takes 
into account the constraints that are still in the goal and those for which the 
set and deletion semantics rules have not yet fired. In the rest of this section, 
we first show how CHR execution states are normalized and then show that in a 
Logical Algorithms state and its corresponding normalized CHR execution state, 
corresponding rule instances can fire. We start by defining a pre-normal form. 

Definition 1 [Pre-normal Form) 

A (reachable) state a is in pre-normal form if and only if a = (0, S, true,T) n , 
all constraints in S are of the form a r (X,M)#i, and if a r (X, M%)#ii £ S and 
a r (X, M 2 )#«2 £ S then i\ = i 2 (and consequently Mi = M 2 ). 

The following lemma shows that every reachable state is pre-normalized before rules 
are tried with priority > 2. 

Lemma 1 (Pre-normalization) 

Up 

For every reachable state a, there exists a finite derivation D = a >— *y(p) °~* such 
that a* is in pre-normal form, chr_to_la(o-) = chr_to_la(er*), and all rules fired in D 
have priority 1 or 2. Every state has a unique pre-normal form with respect to the 
chr_to_la mapping function. 
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Proof 

We introduce the following ranking function on CHR states: 

|M| = 2 • \{a(X) | a(X) e A} W {del(a(X)) \ del(a(X)) E A}\ + \G\ 

where a = (G, S,true,T) n , A = G ttl chr(S) and if X is a (multi-)set, |X| is its 
cardinality. Clearly, the rank of any state is positive, and if ||er|| = 0, state a is in pre- 
normal form. If a is not in pre-normal form, then there exists at least one transition 
a >— >t(p) a ' ■ We show that for all such transitions chr_to_la(cr) = chr_toJa(cr') and 
||ct'|| < ||ct||, which ensures termination. 

If the goal G is not empty, then only the Introduce transition is applicable. 
Every application of this transition moves a CHR constraint from the goal to the 
CHR constraint store, so ||er'|| = ||er|| — 1. By definition, chr_toJa(cr') = chr_to_la(cr) 
(because the chr_to_la function does not distinguish between the goal and the CHR 
constraint store). 

If the goal G is empty then given that a is not in pre-normal form, chr(5) contains 
a constraint of the form a(X) or del(a(X)). We look into detail to the case of 
a(X) £ chr(5); the case of del(a(Xj) e chr(5) is similar. We start by showing 
that at least one rule of priority 1 or 2 is applicable. Next, we show that each rule 
application decreases the norm and maintains the invariance with respect to the 
chr_to_la function. 

Assume a(X) G chr(S). If a r (X,-p) e chr(S) or a r (X,b) e chr(S) then the 
following rule of T(P) is applicable: 

1 :: a r (X, M) \ a(X) M ^ n | true 

If a r (X,n) e chr(5) then the rule below applies: 

1 :: a r (X, n), a(X) ^=^> a r (X,~b) 

Finally, if no rule of priority 1 can be applied, which implies that no constraint of 
the form a r (X, M) G chr(S'), then the following T(P) rule can fire: 

2 :: a(X) ^ a r {X,p) 

This covers all possibilities. Now we look at what happens after firing one of the 
priority 1 or 2 rules. The rule 

1 :: a r (X, M) \ a(X) ^=> M ^ n | true 

removes a constraint a(X)#i from S and has an empty body, so \\o-'\\ = ||<r|| — 2. 
Since M ^ n the removed constraint was already represented by the a r (X,M) 
constraint and so chr_toJa(er') = chr_to_la (a). Firing 

1 :: a r (X,n),a(X) a r (X, b) 

causes the removal of two constraints from 5, namely a r (A > ,n)#i and a(A > )#j. 
Furthermore, it adds a new constraint a r (X,~b) to G. This results in |jer'|| = \\a\\ — 1. 
The new constraint represents the combined mode of both removed constraints and 
hence chr_toJa(er') = chr_to_la(cr). Finally, the rule 

2::a(X) <=^ a r (X,p) 
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is only applicable if chr(S) does not contain a constraint of the form a r (X,M). 
It removes a constraint a(X)#i from S and adds a new constraint a r (X,p) to G, 
resulting in ||ct'|| = ||ct|| — 1. The new representation covers the positive assertion 
and so chr_to_la(er') = chr_to_la(er). 

In summary, if the goal is empty and a is not in prc-normal form, a rule of 
priority 1 or 2 can fire and so no rule with lower priority is applicable. All ap- 
plicable transitions strictly decrease the value of the ranking function and so the 
pre-normalization terminates. Finally, none of the possible transitions changes the 
value of chr_to_la. □ 

The state a* is called a pre-normalization of a. 
Definition 2 {Implied Rule Instance) 

A rule instance 9(r) is implied in a state a if 0(C) C chr_to_la(cr) with 9(a) the 
conclusion of 0(r). 

Lemma 2 (Normalization) 

Let there be given a pre-normalized state a = (0, S, true,T) n . If there exists 

a transition a >—>t(p) °~ m which an implied rule instance fires, then the pre- 
normalization of a' has the form (0, S, true,T') n > with T" D T. In other words 
chr_toJa(cr) = chr_to_la(a') and the CHR constraint store after pre-normalization is 
unchanged from the one before the implied rule instance fired while the propagation 
history is increased. 



Let 9(r) be the implied rule instance with conclusion 9(C). Since 9(C) C chr_toJa(er) 
with a = (0, S, true, T) n , we have a' = (9(C), S, true, T U {t}) n and chr_toJa(er) = 
chr_toJa(er') with t the propagation history tuple corresponding to 9(r). The goal 
G of a' equals 9(C) and so it holds that if a(X) e G then a(A,p) e chr(5) or 
a(X,b) e chr(S) and if del(a(X)) £ G then a(X,n) £ chr(S) or a(X,b) £ chr(S). 
Now all constraints in the goal are first introduced in the CHR constraint store. 
Next, the newly introduced CHR constraints are removed one by one using one of 
the following rules: 



These rules remove all the constraints that were introduced from the goal and do 
not change the rest of the CHR constraint store, hence after pre-normalization, the 
CHR constraint store equals that of state a again. □ 

Because the CHR constraint store remains unchanged after firing an implied rule 
instance and pre-normalizing the resulting state, only finitely many such rule in- 
stances can fire before either reaching a final execution state, or a state in which a 
non-implied rule instance can fire. We call such a state normalized. 



Proof 




1 :: a r (X,M) \ del(a(X)) 



M ^ p | true 
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Definition 3 {Normal Form) 

A pre-normalized CHR execution state a is in normal form if it is a final state 

(a >t^t<p)) or there exists a transition a >— >t(p) °~' such that chr_to_la(cr') ^ 
chr_toJa(cr), i.e., in which a non- implied rule instance is fired. 

Lemma 3 

For every Logical Algorithms state ola and every normalized CHR execution state 

a = (0, S, true, T) n such that ctla = chr_to_la(<7), there exists a transition <tla m p 

o~' LA if and only if there exists a transition a >^t{P) °~' firing a non-implied rule 
instance such that a' LA — chr_toJa(cr'). 

Proof 

A transition of g^a to a' LA implies there exists a fireable rule instance 0{r) of a 
rule r in P with priority p of the form 

r@p:A 1 ,...,A n ^C 

Let {A u , A c ) = ([Af, A™ ], [A\, Af]) = split([Ai, . . . , A n ]) where we use the 
split function defined in Section [3Tl The user-defined antecedents can be partitioned 
into sets of syntactically equal antecedents with respect to the matching substitution 
9. The following function returns this partition: 

substitution_to_partition(6>, [A™, . . . , A^J) = {Si, . . . , S m } 

where Si = {j \ 0(Af) = 9(Af)}. Let p = substitution_to_partition(6>, A u ). From the 
partition, we find the most general unifier 9' that unifies all antecedents {A" | i G S} 
for every S e p: 9' = partition_to_mgu( j o, A u ) with partition_to_mgu as defined in 
Section [niU Clearly, 9' exists and is more general than 9. The applicability of the 
Apply transition means that for all comparison antecedents A\ with 1 < i < I, 
T> |= 0(AD and so it holds that T> \= 3^9' '(A\ A ... A A^) and consequently a rule r p 
exists. This rule looks as follows: 

p + 2::r p @H u ...,H k => gi ,g 2 \C' 

with {[H 1 ,...,H k lg 1 ) = modes(AO, Af = [A{,...,A{] = filter(0'(A tl ), p), g 2 = 
0'(A C ) and C = 9'(C). The modes and filter functions are as defined in Section l3Tl 

Let 9" be a ground matching substitution such that 9 = 9"\ vars ^g) o 9' where 
9"\vars{6) is the projection of 9" on the variables in 9. Since 6' is more general 
than 9, 9" exists. For all i G {l,...,fe}, if A{ = a(X) then Hi = a r (X,p). Be- 
cause of the applicability of Logical Algorithms rule r in state gla, 9"{a{X)) G 
a LA and 9" {del(a(X))) <£ a LA , so H[ = 9"(a r (X, p))#i^ £ S and 6>"(iJ 2 ) = 
chr(_ff l '). Similarly, if A{ = del(a(X)) then Hi = a r (X, A) and g\ contains JV^p; 
9"(del(a(X))) G ctla and as a result Jf? = 9" {a r {X , N'))#id l G 5 with A' = n or 
A' = b. Since A only appears in Hi and the guard JV/p, we can further impose 
that 6"(N) = N' and then 9"(H l ) = chr(ff'). 

All 6»"(Af) are different for 1 < i < fc, and therefore, all ia\ must be different. 
From V |= 3 0(A£ ) for 1 < i < Z and because 0"(gi) = [Nt p, . . . , N ^ p] with 
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Nj = n or Nj = b for 1 < j < o, V |= true -> ^6"(g x Ag 2 )- We conclude that 9" 
is a ground matching substitution that matches the head with constraints from 5* 
and for which the guard is entailed. 

It is not possible that (r p ,id(H)) G T because chr_to_la grows monotonically, 
which implies that 9(C) = 9"(C) G chr_to_la(er) = ctla which contradicts with the 
applicability of 9(r) in a la- 

If we ignore rule priorities, all conditions are satisfied so that rule instance 0(r p ) 
can fire. The resulting state a 1 has the form (9(C), S, true, T U {(r p ,\d(H))}) n . 
Clearly, if ola = chr_to_la((0, S, true, T) n ) and o' LA = cfla U 9(C) then a' LA — 
chr_toJa(cr'). We now prove that every CHR transition firing a non-implied rule 
instance corresponds to a Logical Algorithms transition, also ignoring rule priorities. 
Both results combined give us that the priority of the highest priority rule instance 
is equal in both a and <tla- 

A transition of a = (0, S, true, T) n to a 1 implies that T(P) contains a rule 

p + 2::r p @H => 9l ,g 2 | C 

and so the Logical Algorithms program P contains a rule 

r@p:A 1 ,...,A n ^C 

Let (A U ,A C ) = split(L4i, . . . , A n ]) and 9 = partition_to_mgu(/9, A u ). If A 4 = a(X) e 
A u then 9(a r (X,-p)) £ H. If A, = del(a(X)) G A u then 9{a r (X,N)) G H and 
(N ^ p) G g\. Finally, if A l G A c then G 52- There exists a (ground) 

matching substitution 9' such that 9'(H) G chr(S') and £> ^ zi©^' (51 A (72)- 

Let 6*" = 9' o 9 and let (7^^ = chr_to_la(er). Because 0' is a ground substitution, 
I? |= B$6'(gi A ,g 2 ) implies that for all A t G A c , I? (= 6"(Ai). For all positive user- 
defined antecedents = a(-?) G A", we have that 9"(a(X,p)) G chr(S') and so 
0" (Ai) G a la and deZ(0"(Ai)) ^ ctla- For all negative user-defined antecedents 
A{ = del(a(X)) G A", we have that 9"(a r (X, N)) G chr(S) with iV = b or ]V = n 
and so 9"(Ai) E (Tla- We have assumed that 9'(r p ) is not an implied rule instance 
and so 9'(C')=9"(C) a LA - 

If we again ignore rule priorities, all conditions are satisfied so that rule instance 
6"(r) can fire in state ula and it holds that a' LA = (Tla U 6"(C) = chr_to_la(o-') 
since a' — (9'(C), S, true, T U {(r p , \d(H))}) n . Now we have that both the original 
program P and its translation T(P) can fire corresponding rule instances if we 
ignore priorities, and so their highest priority rule instances also correspond. □ 

Theorem 2 

UJ p 

For every reachable CHR rp state a, if a >—*t(p) °~' then either chr_to_la(cr) = 

LA 

chr_to_la(cr') or chr_toJa(er) chr_toJa(cr'). 

Proof 

Implied by Lemmas [U [5] and [H □ 
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Theorem 3 

For every Logical Algorithms state Oi and reachable CHR rp state a[ such that 
chr_toJa(erQ = oi, there exists a finite CHR rp derivation a[ >—►£/■ m cr', for which 



'T(P) 



LA 



holds that chr_to_la (o~[, ) — o~i such that if Cj >— >p <7j then cr,-* >— >t(P) with 
chr_to_la((Tj ) = cr, and if <7j is a final state then cr^» is also a final state. 

Proof 

Implied by Lemmas [1] [5] and [31 □ 



Given a Logical Algorithms state cr, we can use (cr, 0, true, 0}i as initial state for 
the CHR rp derivation. Theorem [3] is illustrated by the figure below. 




(crj,0,trae,0)i ^p(P) cr^ ^-> T(P) cr^ 



LA 
CTi >-^p (Tj 



cr,-. 



LA 



+ T(P) 



3.3 Weak Bisimulation 

To capture the meaning of the above correspondence results, we relate them to the 
notion of (weak) bisimulation. A bisimulation is a relation between the states of a 
labeled transition system (LTS). A relation R C S\ x 52 between the states in S\ 
and those in Sa is a bisimulation if p R q and p p 1 implies that q A q' with 
p' R q' , and similarly, p R q and q ^ q' implies that p p' with p' i? c/. Here, a is 
the label of the transition p A p' from state p to state p'. If a transition from p to 
p' has no observable effect, it is called a silent transition and denoted by p — » p'. 
A relation i? C Si x S2 is a weafc bisimulation if p R q and p ^> p' implies that 
q — > c/» A q£ c/' with p' i? c/', and vice versa with the roles of p and q swapped. 

T * 

Here p — > p' means p and p' are linked by zero or more silent transitions. 

Let 5*1 be the set of valid Logical Algorithms states for program P and let S% = 

{chr_to_la (cr) | (G, 0, true, 0)i ^-^(p) °~ ^ G E S±}, i.e., S2 is found by applying 

the chr_to_la mapping function all reachable CHR rp states for program T(P). We 

transform the state transition systems for Logical Algorithms and CHR rp to labeled 

. . la 

transition systems as follows: a Logical Algorithms transition a a corresponds 
to an LTS transition a —> a' with a = a' \ cr, i.e., a represents the state change 

Up 

from a to cr'. A CHR rp transition a >— >t(p) c corresponds to an LTS transition 
chr_to_la (cr) A c hr_to_l a (cr') with a = chr_to_la(cr') \ chr_to_la(cr) if this set is not 
empty and a — r otherwise. 

Corollary 1 

The equality relation between the states of S\ and S2 is a weak bisimulation. 
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4 Translating a subset of CHR rp into Logical Algorithms 

In the previous section, we have shown that Logical Algorithms programs can be 
translated into equivalent CHR rp programs. In this section, we show how to do 
the opposite, i.e., how CHR rp programs can be translated into equivalent Logical 
Algorithms programs. This allows us to apply the meta-complexity theorem for 
Logical Algorithms to the translation of these CHR rp programs. 

We impose some restrictions on the CHR rp programs that can be translated. 
These restrictions result from the fact that the Logical Algorithms language does 
not have the concept of an underlying constraint solver that offers both ask and tell 
built-in constraints. In principle, the complete CHR rp language could be translated 
into LA, as the subset of CHR rp for which we propose a translation is already 
Turing complete ( |Sneyers 2008[ Chapter 10), and therefore so is the LA language. 
However, in general, this requires a LA implementation of the built-in constraint 
solver used by the CHR rp program. Since this built-in solver is not part of the 
CHR lp program, we restrict our translation schema to programs that do not make 
use of such a solver. In particular, we only support the translation of the positive 
range-restricted ground segment of CHR rp (jBetz 2007P : 

1. In all reachable states a = {G,S,B,T) n : vars(S) = 0. In words, all (stored) 
CHR constraints are ground. 

2. All built-in constraints are comparisons; there are no built-in tell constraints. 

The first property holds if the initial goal is ground and all rules are variable re- 
stricted, which means that all variables in the body of a rule, also appear in one 
of the rule heads. The second property implies that all reachable states are of the 
form (G, S, true, T) n , i.e., the built-in constraint store always equals true. 

To simplify the presentation, we also assume that the priority of dynamic priority 
rules is determined by the arguments of its left-most head. In general, we can use the 
transformation schema given in Section 12.2.31 to ensure that the resulting Logical 
Algorithms rules have the correct syntactical form. 



We now show how the rules of a CHR rp program P are transformed into Logical 
Algorithms rules that form a program T(P). To increase readability, we distinguish 
between simplification and simpagation rules on the one hand, and propagation 
rules on the other. A simpagation rule of the form 



r' @ p : H{ d , H ld , Alldiff, g, next_id{Id next ) 

del(H{ d ), del{H%), del{nexUd{Id next )) , 
B ld , Bf, next_id{Id next + o) 

where H id = c(X ,Id t ) if H t = c(X), B id = c(X ,Id next + i - 1) if B, = c(X) 
and Alldiff= {{Id% ^ Idj) | V |= BgHj = Hj A g}. The disequalities in Alldiff are 



4-1 The Translation Schema 




is transformed into 
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between those heads that are unifiable and for which the guard is still satisfiablc 
after this unification. The next _ id/ 1 antecedent is used to retrieve the next free 
identifier to be used to identify constraints in the body, cf. the uj p operational 
semantics of CHR rp . The case of a simplification rule is similar. A propagation rule 
of the form 

p::r @ H u ...,H m =^ g\B u ...,B 
is transformed into the following two rules 

r[ @ p : H\ d , H!l Alldiff, g token(r, [Id u ..., Id m ]) 

r' 2 @p: H{ d , H%, Alldiff, g, token(r, [Idi, Idm]), nexUd(Id next ) => 

del(token(r, [Id\, . . . , Idm])), del(nextJd(Id ne xt)), 

B\ d , . . . , Bf, nexUd(Id next + o) 

where H\ d , B %d and Alldiff are as before. The first of these rules generates a token. 
This token is removed by the second rule. The tokens are needed to prevent a 
given rule instance from firing more than onced Note that the transformation into 
two rules and the use of tokens does not increase the complexity compared to the 
original rule, as there is only one token for each combination of rule and constraint 
identifiers (as well as only one positive next_id/l assertion in any state). 

The initial database consists of the goal (where each constraint is extended with 
a unique identifier) and a next_±d(Id next ) assertion (with Id nex t the next free 
identifier) . 

Example 6 (Merge Sort) 

The following CHR rp program implements a merge sort algorithm. Its input consists 
of a series of n (a power of 2) number/1 constraints. Its output is a sorted list of 
the numbers in the input, represented as arrow/2 constraints, where arrow (X ,Y) 
indicates that X is right before Y . 



1 : : 


msl 


3 arrow(X,A) \ arrow(X,B) <=> A < B I arrow (A, B) . 


2 : : 


ms2 


3 merge (N, A) , merge (N,B) <=> A < B I merge(2*N+l,A) , arrow (A, B) . 


3 : : 


ms3 


3 number(X) <=> merge(0,X). 


Its Lo 


gical Algorithms translation is 


msl' 


9 1 


arrow(X,A,Idi) , arrow (X,B, Id 2 ) , A < B, next_id(NId) => 






del(arrow(X,B,Id2)) , del(next_id(NId) ) , 






arrow(A,B,NId) , next_id(NId+l) . 


ms2' 


S 2 


merge(N,A,Idi) , merge (N,B, Id 2 ) , A < B, next_id(NId) => 






del (merge (N, A, Id! )) , del (merge (N, B , Id 2 )) , del (next_id(NId) ) , 






merge(2*N+l,A,NId) , arrow(A,B,NId+l) , next_id(NId+2) . 


ms3' 


9 3 


number (X , Id) , next_id(NId) => del (number (X, Id) ) , 






del(next_id(NId)) , merge (0, X, NId) , next_id(NId+l) . 



3 In (Dc Koninck ct al. 2007a|, an erroneous translation was presented which did not use tokens, 
and in which a propagation rule could fire infinitely many times because the constraints in the 
body are assigned new identifiers each time the rule is fired. 
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Note that in rules msl and ms2, the guard prevents the constraints matching the 
heads from being equal, and so there are no disequality constraints between the 
CHR constraint identifiers. In (|De Koninck et al. 2007aP it is derived that the total 
runtime of this Logical Algorithms program is 0(n\ogn). We defer the complexity 
analysis of the merge sort algorithm to Section 16.11 where we analyse the CHR rp 
implementation directly using a new meta-complexity theorem for CHR rp . 

Example 7 (Less-or-Equal) 

To illustrate how propagation rules are dealt with, we show the translation of a 
rule of the leq program which is given further on in Example [51 The rule 

3 :: transitivity @ leq(X,Y), leq(Y,Z) ==> leq(X,Z) . 



is translated into 

trans it ivityi ® 3 : leq(X,Y,Idi) , leq(Y,Z,Id 2 ) , Idi \= Id 2 => 

token(transitivity , [Idi ,Id2] ) . 
transitivity 2 3 : leq(X,Y,Idi) , leq(Y,Z,Id 2 ) , Idi \= Ida, 
token(transitivity, [Idi ,Id2] ) , next_id(NId) => 

del(token(transitivity , [Idi , Id 2 ] ) ) , del(next_id(NId) ) , 

leq(X,Z,NId) , next_id(NId+l) . 



Note that since in the original rule, the two heads leq(X,Y) and leq(Y,Z) are 
unifiable (and there is furthermore no guard to prevent this from happening), we 
have to add an explicit disequality between the constraint identifiers for these heads: 
Id! \= Id 2 . 

4-2 Correspondence 

In this subsection, we prove that a CHR rp program and its translation to Logical 
Algorithms are operationally equivalent. Again we introduce a mapping function: 

la_to_chr(cr) = (0,5, true,T) n 

where the CHR constraint store S = {c(X)#Id \ c(X, Id) e a A del(c(X, Id)) a}, 
the propagation history T = {(R, Ids) \ del{token(R, Ids)) £ a}, and the next free 
identifier n is such that nextjid(n) 6 a and del{next_id{n)) ^ a. In the following, we 
consider a Logical Algorithms state a reachable with respect to program T(P) if it 
can be derived from an initial state consisting of CHR constraints extended with 
unique identifiers, and a single next_id/l assertion with as argument the next free 
identifier. In this case, reachability amongst others implies that there can be only 
one (strictly) positive next_id/l assertion in any state, and no two CHR constraint 
representations share their identifier. 

First, we define the priority-ignoring operational semantics LA' of Logical Algo- 
rithms, as being the same as its regular operational semantics except that priorities 
are ignored, i.e., the next applicable rule instance in any state is independent of 
the priorities. Next, we state two lemmas that relate a CHR rp program P and 
its translation T(P) under respectively the theoretical operational semantics w t of 
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CHR and this priority-ignoring operational semantics LA' of Logical Algorithms. 
Note that the u t semantics of CHR also ignores rule priorities. 

Lemma 4 

LA' 

For every reachable Logical Algorithms state Oi it holds that if <7j >— > t(p) then 
either it holds that la_to_chr(<7j) = la_to_chr((jj) or there exists a finite CHR deriva- 

tion la.to.chr(o-i) = (0, S,true,T) n ^ P (C,S',true,T') n (®,S",true,T') n , = 
la_to_chr(crj) consisting of an Apply transition, followed by zero or more Introduce 
transitions. 

Proof 

LA' 

Consider a transition o~i >— > tip) o~j ■ The only type of transition in Logical Algo- 
rithms is the Apply transition which fires a rule. If la_to_chr(cr i ) = la_to_chr(crj), 
then this rule must be of the form 

rj © p : H id , H id , AlULiff, g => token{r, [Ld u . . . , Id m ]) 

because all other types of rules either delete the representation of a CHR constraint 
which changes the CHR constraint store, or remove a token which results in an 
extended propagation history. We call the fired rule a token generation rule. 
If la_to_chr(<7i) ^ la_to_chr(er.,) and the rule fired is of the form 

r' @ p : H id , H id , Alldiff, g, next_id{ld next ) => 

del(H{ d ), del(H^), del{nexUd{Id next )) , 
B[ d , B l a d , nexUd{Id next + o) 

which corresponds to a simplification (I = 1) or simpagation (I > 1) rule. We further 
assume the case of a simpagation rule; the case of a simplification rule is similar. If 
r' e T(P) (with I > 1), then P contains a rule 

p::r @ H lt ..., Hi_{\H h ...,H m g\B 1 ,...,B a 

Since the conditions for the Logical Algorithms Apply transition are satisfied, 
there exists a ground matching substitution 8 such that for each antecedent H\ d = 
c{X,Ldi) (1 < i < m) it holds that 6{W d ) e a and del{Q(H\ d )) £ a and so by 
definition of the la_to_chr function, 8(Hi#Ldi) G S where la_to_chr((Ji) = a\ — 
(0, S, true, T) n . For each comparison gt G g, it holds that V \= 0(gi) and so V \= 
true — > 300(g). Since r is a simpagation rule, the propagation history T does not 
contain any element of the form (r, _) . In summary, all conditions are satisfied such 
that the rule instance 9(r) can fire in state a\ under operational semantics w t . 

After firing B(r) in state a[, the resulting state equals (0(B\A. . .f\B ), S' , true, T) n 
where S' — S \ {6(Hi#Idi), . . . , 9(H m #Ld m )}. In this state, we can apply the In- 
troduce o times before reaching a state with an empty goal. There are o! pos- 
sible orders in which the introductions can be applied; the one we need is the 
order in which the Bi constraints appear in the rule body. Following this order, 
the state resulting from the introductions equals a'j = (®,S",true,T)( n+0 ) where 
S" = S' U {6(Bi)#n, 0(B o )#(n + o - 1)}. It is easy to see that this state o' 3 



22 



Leslie De Koninck 



equals la_to_chr(crj), the state resulting from firing Logical Algorithms rule instance 
0(r') in state <Ji. 

If la_to_chr((7j) ^ la_to_chr(<r :) ) and the rule fired is not of the form shown above, 
then it must have the following form 

r' 2 @ p : H\ d , H%, Alldiff, g, token(r, [Idi, Idm]), nexUd(Id next ) => 

del(token{r, [Idi, . . . , Idm])), del(next_id(Id nex t)) , 
B ld , B ld , nexUd(Id next + o) 

the corresponding CHR rp rule in P looks like 

p::r @ H u ...,H m =>■ g\B 1 ,...,B 

Again, since the conditions for the Logical Algorithms Apply transition are satis- 
fied, there exists a ground matching substitution 9 such that for each antecedent 
R\ d = C (X, Idi) (1 < i < m) in rule r' 2 it holds that 9{Hf) E a and del(9(H^ d )) <£ a 
and so by definition of the la_to_chr function, 9(Hi#Idi) S S where la_to_chr((7i) = 
a[ = (0,5, true,T) n . For each comparison G g, it holds that T> \= 6(gi) and so 
T> \= true — > 3ijj9(g). The propagation history T cannot contain (r, 9{[Id\ 1 . . . , Idm])) 
because by definition of the la_to_chr function this would imply that the atom 
token(r, 9{{Id\, . . . , Idm)) was deleted in some earlier state, which contradicts with 
the applicability of the Apply transition on rule instance 9{r' 2 ). Again, all condi- 
tions are satisfied such that 9{r) can fire in state a[. 

After firing 9(r) in state ct-, the resulting state equals {6{B\f\. . .AB a ), S, true, T') n 
where T" = T U {(r, [Idi, ■ ■ ■ ,Id m ])}- In this state, we can apply the Introduce 
transition o times before reaching a state with an empty goal. Given again that 
these introductions are applied in the order in which the Bi constraints appear 
in the rule body, then the resulting state equals a'j = (0, S', true, T")( n+0 ) where 
S' = Sl){9(Bi)#n, . . . , 9(B )#(n + o— 1)}. It is again easy to see that this state a'j 
equals la_to_chr(<Tj), the state resulting from firing Logical Algorithms rule instance 
6{r' 2 ) in state a*. □ 



Lemma 5 

For every reachable CHR rp state <7j and reachable Logical Algorithms state with 

LA' 

la_to_chr((T 4 ') = cr,, there exists a finite Logical Algorithms derivation a[ >— >tip) a i' 

with la_to_chr(er^ ) = <Xj such that if Oj = (0, S, true, T) n >-> P (C, S' , true, T') n 
(0, S" ,true,T') n i = Oj where the derivation consists of a single Apply transi- 

LA ' 

tion, followed by zero or more Introduce transitions, then a it >— » t{p) Oj with 
la_to_chr((T^) = (Tj and if ct; is a final state then o^, is also a final state. 

Proof 

Let there be given a reachable Logical Algorithms state with la_to_chr((T J ') = <x;. 
Because of Lemma HI state cr, is also reachable in CHR rp with respect to program 
P. Assume ^ = (0, S, true, T) n ^ P (C, S' , true,T') n y> p (0, S" ' ,true,T') n , = a 3 
where the derivation consists of a single Apply transition, followed by zero or more 
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Introduce transitions, and let 9(r) be the CHR rp rule instance that fired in state 
(Tj. If r is simplification (1 = 1) or simpagation (I > 1) rule 



then 6(Hi)#idi G S for 1 < i < m with id, ^ idj if i ^ j, and T> \= 3tj l 9(g). 
Furthermore, T(P) contains a rule 



Now let 9' be a ground matching substitution such that 0'\ V ars(9) — & where 0' vars fg\ 
is the projection of 9' on the variables in 9, and such that both 6' (Idi) = id* 
for 1 < i < m and 8' (Id nex t) = n - Since for 1 < i < m, if? = c(X,Idi) if 
Hj = c(X), it holds that G u[ and del(8'(Hf)) <£ a[. Also, 2? |= 3 %) 

implies V \= d(gi) for each comparison gi G g. Note that because is ground, 
there is no existential quantification. The Alldiff conditions hold because 9'(Idi) = 
9' (Idj) implies that i = j. Finally, because of the reachability of state a' it there is 
exactly one strictly positive next_id/l assertion in o~[ whose argument equals n. 
Finally, the rule conclusion cannot be already included in the state a[ because it 
includes amongst others the deletion of at least one of the antecedents. Therefore, 
all conditions are satisfied such that rule instance 9'(r') can fire in state a' i: resulting 
in a state a'j = la_to_chr(<7j). 

Now assume that in the CHR rp state cr,, a rule instance 9(r) fires where r is a 
propagation rule: 



In this case the Logical Algorithms translation T(P) contains the following rules: 

r[ @ p : Hl d , H l n d , Alldiff, g token(r, [Id!,..., Id n ]) 

r' 2 @ p : H[ d , . . . , H %d , Alldiff, g, token(r, [Idi, . . . , Idn}), nextJd(Id next ) => 

del(token(r, [Idi, . . . , Idn])), del(next_id(Id ne xt)), 

B\ d , B\ d , nexUd(Id nex t + I) 

A similar analysis as above shows that there exists a matching substitution 9' with 
0'\vars(8) — @ an d both 9' (Idi) — idi for 1 < i < m and 9'(Id next ) — n, such that rule 
instance 9'(r[) can fire (ignoring priorities) if token(r, [idi,..., id n ]) £ o~[ and 9'(r' 2 ) 
otherwise. If 9'(r[) fires then the resulting state a-, = a ■ U {token(r ; [idi, id n ])} 
and clearly la_to_chr(cr^ ) = la_to_chr(cr J -). Moreover, in state a[, , rule instance 0'(r' 2 ) 
can fire and for the resulting state a'j it holds that la_to_chr(<7j) = o~j. If already 
token(r, [idi, • ■ • , id n ]) G <j[ then the same reasoning holds with a[ — o~[, . 

Finally, assume that CHR rp state <7j is a final state. If a'i is not a final Logical 
Algorithms state, then because of Lemma IH the only applicable rules are those 
that do not change the result of the la_to_chr function. Only the token generation 
rules satisfy this property. Since they only generate tokens and these tokens do not 




r' @ p : H{ d , ...,H%, Alldiff, g, nexUd(Id next ) 

del(Hl d ), del(H ld ), del(next_id(Id next )), 
B\ d , B ld , next_id(Idnext + o) 
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appear in their antecedents, these rules can fire only finitely many times before a 
final Logical Algorithms state a> is reached. □ 

Finally, we state two theorems that essentially are the same as the lemmas above, 
except that they do take into account rule priorities. 

Theorem 4 

LA 

For every reachable Logical Algorithms state it holds that if <7j >— >x(P) a ji then 
either it holds that la_to_chr((7i) = la_to_chr((7j) or there exists a finite CHR deriva- 
tion la_to_chr(>;) = (0, S, true, T) n ^ P (C,S',true,T') n ^>* P (0, S", true, T') n , = 
la_to_chr(crj) consisting of an Apply transition, followed by zero or more Introduce 
transitions. 

Theorem 5 

For every reachable CHR rp state cr, and reachable Logical Algorithms state a[ with 

LA 

la_to_chr(c^) = <7,, there exists a finite Logical Algorithms derivation a[ >— °i* 

U)p LJp 

with la_to_chr((T^ ) = m such that if Oi = (0, S, true,T) n >-^p (C, S , true,T') n 
($,S",true,T')„r = Oj where the derivation consists of a single Apply transi- 

LA 

tion, followed by zero or more Introduce transitions, then er^, ^t(p) °j with 
la_to_chr(cTj) = Oj and if Oi is a final state then a[, is also a final state. 

Proof 

Both theorems are implied by Lemmas 0] and combined with the fact that in 
corresponding states, corresponding rules can fire which have the same priority. 
Therefore, the highest priority applicable rule instances are also equal in corre- 
sponding states. □ 



5 Implementing CHR rp , the Logical Algorithms way 

This section presents a new implementation for CHR rp , based on the implementa- 



tion proposal for Logical Algorithms presented in ( Ganzinger and McAllester 2002 ), 
as well as on the scheduling algorithm presented in (|De Koninck 2007). The purpose 
of this implementation is not to replace our existing CHR rp implementation as pre- 
sented in (|De Koninck et al. 2008|) , but to support a new meta-complexity theorem 
for CHR rp , based on the result for Logical Algorithms, and extended towards the 
full CHR rp language. This includes in particular support for non-ground constraints 
and a built-in constraint theory. We note that a better worst case complexity for 
certain operations is not always worthwhile in practice due to larger constant factors 
in the average case. Also, the proposed implementation may not always achieve a 
better complexity than the existing implementation. The main purpose remains to 
have a relatively straightforward way to derive for a given CHR rp program, a bound 
that is guaranteed to be an upper bound for at least the implementation proposed. 
Since the meta-complexity result is insensitive to constant factors, we can present 
the new implementation as a source-to-source transformation to regular CHR. 
The proposed implementation consists of the compilation of the CHR rp rules 
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of the input program into regular CHR rules in which matching is made explicit, 
combined with a scheduler module that is responsible for the execution control. 
The implementation is correct if it is executed according to the refined opera- 
tional semantics of CHR (|Duck et al. 2004} . which describes the execution strat- 
egy followed by most current CHR implementations. We have based our imple- 
mentation on the high-level implementation proposal for Logical Algorithm of 
(Ganzinger and McAllcstcr 2002), extended where necessary to support general 
built-in constraints. By using a CHR implementation with advanced indexing sup- 
port, like for example the K.U.Leuven CHR system ( |Schrijvers and Demoen 2 004), 
our implementation also offers strong complexity guarantees that facilitate a new 
meta-complexity theorem for CHR rp , similar to the one for Logical Algorithms (see 
Section [6]). In the following, we make use of Prolog as CHR's host language, but 
the implementation can easily be adapted to work with a different host language. 



5. 1 Overview 

The implementation is based on a form of lazy (on-demand) matching with retain- 
ment of previously computed partial matches. It combines the concept of alpha 
and beta memories from the RETE algorithm ( |Forgy 1982[ ), with lazy matching 
as for example implemented by the LEAPS algorithm (jMiranker et al. 1990|) FlThe 
basic idea is as follows. A new constraint can function both as a single headed 
partial or full match, and as an extension of an existing partial match into either a 
new (larger) partial match or a full match. In order to extend partial matches, all 
previously computed matches are stored. A scheduler decides which partial match 
is extended with which constraint, or which full match has its corresponding rule 
instance fired. More details on the scheduler are given in Section l5~3l 

First, to simplify the presentation, we propose an alternative syntax for CHR rp 
rules. An intermediate form CHR rp rule looks as follows: 

p :: r @ si^i, . . . , s n A n ^> B 

where Sj G {+, — , ?} and Aj is an atom for 1 < i < n. If Sj = + or Sj = — then 
Aj must be a CHR constraint and if Si =? then Ai must be a built-in constraint. 
An intermediate form CHR rp rule corresponds to a regular CHR rp rule as follows: 
a term +A corresponds to a kept head A, a term —A corresponds to a removed 
head A, and a term ?A corresponds to a conjunct of the rule guard. The main 
advantage of the intermediate form is that it supports specifying a join order for 
the heads, as well as an evaluation order for the guards. In particular it supports 
specifying the evaluation of part of the guard after having computed only a partial 
rule match. The intermediate form gives us the same syntactical flexibility as exists 
in the Logical Algorithms language where comparisons are interleaved with the 
(kept and removed) user-defined antecedents. 



4 Most current CHR systems, including the K.U.Leuven CHR system and the CHR rp system of 
l|De Ko ninck ct al. 2008 ), use a variant of the LEAPS algorithm for rule matching. 



2G 



Leslie De Koninck 



Consider, in general, a simpagation rule of the form 

p :: r @ H u . . . , Hi\H i+1 , ...,H n ^ g\B 

where the guard g is a conjunction of atomic guards g%, . . . , g rn . We can rewrite this 
rule in intermediate form syntax (amongst others) as follows: 

p :: r @ +H 1 ,..., +H h -H l+1 , . . . , -H n) ?g lt ?g m <^ B 

In the following, we assume that all rules have the following form 

p::r@ ± H u 7g x , ±H 2 , 7g 2 , . . . , ±H n , 7g n ^ B 

where ± means + or — . Each gi (1 < i < n) can be a conjunction of primitive 
built-in constraints, and can in particular also be equal to true. The transformation 
from regular CHR rp syntax to intermediate form syntax can be done automatically 
using the above transformation schema, or by hand. 



Using terminology similar to that of (Ganzinger and McAllester 2002), we refer 



to a partial match, matching the heads H%, . . . , Hi and satisfying the partial guard 
gi A ... A gi-i, as a suspended strong prefix firing. If also the partial guard gi is 
satisfied, we speak of a regular (or non- suspended) strong prefix firing. A constraint 
matching the next head Hj+i is called a prefix extension of such a (regular) strong 
prefix firing. A prefix firing that consists of all heads is (also) called a (suspended 
or regular) rule firing. Here, a rule firing actually means a rule instance that is 
fireable. To avoid confusion, we refer to the actual firing of such a rule firing as 
firing a rule instance. Every prefix firing contains the left-most head and hence 
determines the rule priority. In our implementation, we assume that all guards 
are monotone, i.e., once they are entailed by the built-in constraint store, they 
remain entailed in any later state. This is in fact required by the CHR operational 
(and declarative) semantics, although most current CHR systems also support non- 
monotone (impure) guards like for example var/1 in CHR on top of Prolog. 



5.2 Program- Dependent Part 

The program-dependent part of our implementation (i.e., the part that depends on 
the actual program to be implemented) consists of rules for 

• generating a representation for CHR constraint occurrences and deleting them 
when the represented constraint is removed; 

• generating and scheduling constraints representing prefix firings, prefix ex- 
tensions and rule firings and deleting them when a constituent constraint is 
removed; 

• matching prefix firings with prefix extensions, firing rule instances, and man- 
aging suspended prefix and rule firings. 

The different types of rules of the program-dependent part are illustrated by using 
a running example program, namely Dijkstra's shortest path algorithm, already 
given in the Logical Algorithms language in Example [2] and given here in CHR rp 
intermediate form syntax. To illustrate non-trivial head matching, we have added 
a rule dl that removes simple loops from the input graph. 
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1 : 


: dl ( 


3 -e(V,_,V), 


?true 




<=> 


true. 


1 : 


: d2 ( 


3 +source (V) , 


?true 




<=> 


dist(V.O) . 


1 : 


: d3 ( 


3 -distCV.Di) , 


?true , 


+dist(V,D 2 ) , 


?(D 2 < Di) <=> 


true . 


D + 2 : 


: d4 ( 


3 +dist(V,D) , 


?true , 


+e(V,C,U) , 


?true <=> 


dist(U,D+C) . 



5.2.1 Constraint Occurrence Representation 

Although CHR rp constraints and CHR constraints obviously have the same syntax 
and semantics (i.e., multi-set semantics with non-monotone deletion), we introduce 
a new representation for them to allow unambiguous reference, reduce work in 
case of constraint reactivation, and support the efficient deletion of those prefix 
firings, prefix extensions, and rule firings in which they participate (see further). 
For each CHR rp constraint of predicate c/n, we create a set of unique occurrence 
representations c_occ_i/(n + 1), one for each occurrence of the predicate in a rule 
head. The arguments of a c_occ_i/(n+ 1) constraint consist of the arguments of the 
original c/n constraint, together with a unique constraint identifier that is shared by 
all occurrence representations. This identifier is an uninstantiated variable as long 
as the constraint is in the store and is instantiated the moment that the constraint 
is to be deleted. For each user-defined constraint predicate c/n with m occurrences, 
the occurrence representations are generated using rules of the following form. 

c(Xi X„) <=> c_occ_l(Xi X n ,Id) , c_occ_m(Xi X„,Id). 

For the example program, these rules look as follows. 
source(V) <=> source_occ_l (V, Id) . 

dist(V.D) <=> dist_occ_l(V,D,Id) , dist_occ_2(V,D,Id) , dist_occ_3(V,D, Id) . 
e(V,C,U) <=> e_occ_l(V,C,U,Id), e_occ_2 (V.C.U, Id) . 



5.2.2 RETE Memory Constraints 

Regular and suspended prefix firings as well as prefix extensions are represented as 
CHR constraints. We call them RETE memory constraints because they coincide 
with the alpha and beta memories of the RETE algorithm. The RETE memory 
constraints contain all arguments of their constituent CHR constraints, as well 
as their identifiers. Each RETE memory constraint moreover has its own unique 
identifier. We use the following functors for RETE memory constraints: 

• r_pf _i for a regular (non-suspended) prefix firing of rule r, consisting of i 
heads, and r_pf _i_suspended for its suspended version 

• r_pe_i for a prefix extension, consisting of the i + 1 th head of rule r 

• r_rf for a (regular) rule firing of rule r and r_rf _suspended for its suspended 
version. 

If in a rule r, the partial guard after the i th head equals true, then there is no 
suspended version of the i-headed prefix firings of r, or of its rule firings if r is an 
i-headed rule. In the example program, the following prefix firings, prefix extensions 
and rule firings are defined: 
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• dl_rf/4 

• d2_rf/3 

• d3_pf_l/4, d3_pe_l/3, d3_rf/6 and d3_rf _suspended/6 

• d4_pf_l/4, d4_pe_l/4 and d4_rf/7 

5.2.3 Suspended Prefix and Rule Firings 

Suspended prefix and rule firings are converted into regular prefix and rule firings 
as soon as the relevant part of the guard is entailed. If on the other hand this partial 
guard is disentailed, the suspended prefix or rule firing is removed. Given a rule in 
intermediate form syntax 

p::r@ ± H lt lg x , ±H 2 , ?<?2, . ■ • , ±H n , ?<?„ <=> B 

we generate the following rules: 

• For each z-headed suspended prefix firing: 

r_pf _i_suspended(Xi , . . . ,X m , Idi , . . . , Idi ,SId) <=> 

gi I r_pf_i(Xi,...,X m ,Idi,...,Idi,SId), 

schedule_pf (r_i(Yi , . . . ,Y ; ) ,p,SId) . 
r_pf _i_suspended(Xi , . . . ,X m , Idi , . . . , Idi ,SId) <=> \+ gi I true. 

where Yi, .. . ,Y; are those variables in Xi, . . . ,X m that also appear in -ffi+i 

• For each rule firing: 

r_rf _suspended(Xi , . . . ,X m , Idi , . . . , Id n ,SId) <=> g n I 

r_rf (Xi , .... X m , Idi .... , Id n , Sid) , schedule_rf (p , Sid) . 
r_rf _suspended(Xi , . . . ,X m , Idi , . . . , Id n ,SId) <=> \+ g n I true. 

Note that if gi or g n equals true, then we can apply unfolding to replace occurrences 
of respectively r_pf _i_suspended/ (m + i + 1) and r_rf _suspended/ (m+ n + 1) by 
the bodies of the corresponding rules above (see (fTacchclla et al. 2007[) ). After this 
unfolding step, some of the above rules may be removed. In the example program, 
only a rule firing of rule d3 can be suspended. The code below is generated for such 
a rule firing. 

d3_rf_suspended(V,Di ,D 2 ,Idi ,Id 2 ,SId) <=> 

D 2 < Di I d3_rf (V,Di,D2,Idi,Id2,SId), schedule_rf (1 ,SId) . 
d3_rf_suspended(V,Di ,D 2 ,Idi ,Id 2 ,SId) <=> \+ (D 2 < Di) I true. 



In the second rule above, \+ (C) is a safe approximation of the negation of con- 
straint C, i.e., it is only entailed if constraint C cannot possibly hold. In the Prolog 
context, the built-in negation as failure can be used. 

Suspended constraints are attached to all guarded variables so that they are 
reactivated whenever one of these variables is affected by a built-in constraint. We 
assume that both attaching and detaching can be done in constant time, although 
certain current CHR implementations like the K.U.Leuven CHR system do not 
support detaching in constant time. 
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5.2.4 Scheduling 

Each constraint occurrence corresponds to a (potentially suspended) rule firing if 
it is the only head of a single headed rule, a (potentially suspended) prefix firing if 
it is the first head of a multi-headed rule, and a prefix extension in all other cases. 
A conversion between constraint occurrence and rule firing, prefix firing or prefix 
extension is made as soon as the constraint in question matches with the head. If 
such a match is shown to be impossible, the constraint occurrence is discarded. Let 
there be given a head constraint c(X\, . . . ,X n ). The following function is used to 
construct a head match. 

, /r,n ,>n i (i x \ Y },9) if X is a variable and X 4. vars(X) 

head_match(LY \X ) = < u _ 

\([Y\Y],(Y = X) Ag) otherwise 
where (Y,g) = head_match(A ? ) 
head_match([]) =([],true) 

Now, for each rule in intermediate form syntax 

p::r@ ± H u lg u ±H 2 , ?g 2 , . . . , ±H n , tg n <S=^ B 

and for f < i < n we generate the rules below where Hi — c(X' 1 , . . . , X' n ) is 
the j th occurrence of the user-defined constraint predicate c/n, ([Xi, . . . ,X„], g) — 
head_match([A{, . . . , X' n ]), and {Y x , . . . ,Y m } = vars(Hi) \ vars{{Hi, H l - 1 }). 

• If i = n = 1: 

c_occ_j (Xi , . . . ,X n , Id) <=> g I r_rf .suspended (Yi ,Y m , Id, Sid) . 
c_occ_j (Xi , . . . ,X n , Id) <=> \+ g I true. 

• If i = 1 and n > 1 : 

c_occ_j (Xi , . . . ,X n , Id) <=> g I r_pf _l_suspended(Yi , . . . , Y m , Id.SId) . 
c_occ_j (Xi , . . . ,X n , Id) <=> \+ g I true. 

• Otherwise, if i > 1 : 

c_occ_j(Xi, . . . ,X n ,Id) <=> g I 

r_pe_i - l(Yi Y m , Id, Sid) , schedule_pe {r_i - l(Zi, . . . ,Z ; ) ,SId) . 

c_occ_j (Xi , . . . ,X„ , Id) <=> \+ g I true. 

where {Zi, . . . ,Z;} = vars(Hi) n vars{{H\, . . . , i?i_i}). 

In the above, if g — true then the second rule of each pair of rules can be discarded. 
The suspended prefix and rule firings can sometimes be replaced by regular prefix 
and rule firings by unfolding (see Section [5. 2. 3p . 

In the example program, only the first occurrence of the e/3 constraint has a 
non-trivial head match (the first and last argument must be the same). All prefix 
and rule firings are followed by the trivial guard true and so we only generate 
regular prefix and rule firings. They are scheduled using the schedule_pf /3 and 
schedule_rf /2 predicates. 



source_occ_l(V,Id) <=> d2_rf (V, Id, Sid) , schedule_rf (1 , Sid) . 
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dist_occ_l(V,D,Id) <=> d3_pf_l(V,D,Id,SId) , schedule_pf (d3_l (V) , 1 ,SId) . 
dist_occ_2(V,D,Id) <=> d3_pe_l (D , Id, Sid) , schedule_pe (d3_l (V) , Sid) . 
dist_occ_3(V,D,Id) <=> d4_pf_l(V,D,Id,SId) , schedule_pf (d4_l(V) ,D+2,SId) . 

e_occ_l(V,C,U,Id) <=> V = U I dl.rf (V,C,Id,SId) , schedule_rf (1 ,SId) . 
e_occ_l(V,C,U,Id) <=> \+ (V = U) I true. 

e_occ_2(V ) C ) U,Id) <=> d4_pe_l (C,U, Id, Sid) , schedule_pe(d3_l (V) ,SId) . 



Prefix firings and extensions are scheduled using a key containing their shared 
variables. For example for the prefix firings consisting of the first head of rule d3 
and the corresponding prefix extensions consisting of the second head of the same 
rule, the key equals d3_l (V) . 

Similar to the suspended prefix and rule firings, the constraint occurrences are at- 
tached to all guarded variables. We again assume that both attaching and detaching 
can be done in constant time. 

5.2.5 Matching and Firing 

The scheduler initiates the firing of a rule instance by asserting a f ire/1 constraint, 
and the matching of a prefix firing with a prefix extension by asserting a match/2 
constraint. These constraints have as arguments the identifiers of the corresponding 
RETE memory constraints. After matching a prefix firing with a prefix extension, 
a new suspended prefix or rule firing is generated. For a given n-headed rule r with 
n > 1 and for 1 < i < n — 2, we generate the following rule 

r_pf _i(Xi , . . . ,X m ,Idi , . . . ,Idi ,SIdi) , r_pe_i(X m+ i X; , Id i+ i ,SId 2 ) \ 

match(SIdi ,SId 2 ) <=> Id»+i \== Idi , Id»+i \== Id; I 

r_pf_i + l_suspended(Xi , . . . ,X; ,Idi , . . . ,Idj+i) . 

and similarly for i = n — 1: 

r_pf_n - l(Xi X m ,Idi , . . . ,Id„_i ,SIdi) , r_pe_n - 1 (X m+ i X; ,Id„ ,SId 2 ) \ 

match(SIdi ,SId 2 ) <=> Id n \== Idi Id„ \== Id„_i I 

r_rf .suspended (Xi , . . . , X; , Idi , • • ■ , Id n ) . 

A rule firing of an n-headed rule r with body B is fired as follows: 

r_rf_i(X 1 ,...,X m ,Idi,...,Id n ,SId), fire (Sid) <=> 

ld r (i) = dead, . . . , Id r (/j = dead, B . 

where r(l), . . . , r(l) are the indices of the removed heads of the rule (if any). We 
furthermore add the following rules at the end of the code, to make sure the CHR 
compiler detects that the match/2 and fire/1 constraints are never to be stored. 

match(_,_) <=> true. 
fire(_) <=> true. 

For the example program, the generated code is as follows: 

dl_rf (V,C,Id,SId) , fire(SId) <=> Id = dead. 
d2_rf (V, Id, Sid) , fire(SId) <=> dist(V.O). 

d3_pf_l(V,Di,Idi,SIdi) , d3_pe_l(D 2 ,Id 2 ,SId 2 ) \ match(SIdi ,SId 2 ) <=> 
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Id 2 \== Idi I d3_rf_suspended(V,Di ,D 2 ,Idi ,Id 2) SId) . 
d3_rf(V,Di,D 2 ,Idi,Id2,SId), fire(SId) <=> Idi = dead. 
d4_pf_l(V,D,Idi ,SIdi) , d4_pe_l(C,U,Id2,SId 2 ) \ match (SIdi ,SId 2 ) <=> 

Id 2 \== Idi I d4_pf (V,D,C,U,Idi ,Id 2 ,SId) , schedule_rf (D+2, Sid) . 
d4_rf (V,D,C,U,Idi ,Id 2) SId) , fire(SId) <=> dist(U,D+C). 



match(_,_) <=> true. 
fire(_) <=> true. 



5.2.6 Clean-up 

Whenever a constraint's identifier variable is instantiated, its occurrence represen- 
tations, as well as those RETE memory constraints in which it participates, are 
removed. The rules look as follows. 

• For the i th occurrence representation for constraint predicate c/n: 
c_occ_i(Xi , . . . ,X n ,Id) <=> nonvar(Id) I true. 

• For an z-headed suspended prefix firing of rule r: 

r_pf _i_suspended(Xi X m , Idi , . . . ,Idj ,SId) <=> nonvar(Idi) I true. 

r_pf _i_suspended(Xi , . . . ,X m ,Idi , . . . , Idi ,SId) <=> nonvar(Idi) I true. 

• For an i-headed regular prefix firing of rule r: 

r_pf_i(Xi X m ,Idi Idi, Sid) <=> nonvar(Idi) I remove_pf (Sid) . 

r_pf_i(Xi X m ,Idi Idi, Sid) <=> nonvar(Idi) I remove_pf (Sid) . 

• For a prefix extension of an i-hcadcd prefix firing of rule r: 
r_pe_i(Xi X m ,Id,SId) <=> nonvar(Id) I remove_pe (Sid) . 

• For a suspended rule firing of an n-headed rule r: 

r_rf _suspended(Xi , . . . ,X m , Idi , . . . , Id n ,SId) <=> nonvar(Idi) I true. 

r_rf _suspended(Xi , . . . ,X m , Idi , . . . , Id n ,SId) <=> nonvar(Id n ) I true. 

• For a regular rule firing of an n-hcadcd rule r: 

r_rf (Xi X m ,Idi Id„,SId) <=> nonvar(Idi) I remove_rf (Sid) . 

r_rf (Xi X m ,Idi Id„,SId) <=> nonvar(Id n ) I remove_rf (Sid) . 

The predicates remove_pf /l, remove_pe/l and remove_rf/l remove respectively 
a prefix firing, prefix extension and rule firing from the schedule. The following 
clean-up rules are generated for the example program. 

source_occ_l (V, Id) <=> nonvar(Id) I true. 

dist_occ_l (V,D, Id) <=> nonvar(Id) I true. 

dist_occ_2(V,D, Id) <=> nonvar(Id) I true. 

dist_occ_3(V,D, Id) <=> nonvar(Id) I true. 
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_occ_l(V,C,U,Id) <=> nonvar(Id) I true. 
_occ_2(V,C,U,Id) <=> nonvar(Id) I true. 



dl_rf (V.C.Id.SId) <=> nonvar(Id) 

d2_rf (V.Id.SId) <=> nonvar(Id) 

d3_pf_l(V,Di,Idi,SId) <=> nonvar(Idi) 

d3_pe_l(D 2 ,Id 2 ,SId) <=> nonvar(Id 2 ) 

d3_rf (V,Di,D 2 ,Idi,Id2,SId) <=> nonvar(Idi) 

d3_rf (V ) Di > D 2 ,Idi ) Id 2) SId) <=> nonvar(Id 2 ) 

d4_pf_l(V,D,Idi ,SId) <=> nonvar(Idi) 

d4_pe_l(C,U,Id2 ,SId) <=> nonvar(Id 2 ) 

d4_rf (V.D.C.U.Idi ,Id 2 ,SId) <=> nonvarCld!) 

d4_rf (V.D.C.U.Idi ,Id 2) SId) <=> nonvar(Id 2 ) 



remove 
remove 
remove 
remove 
remove 
remove 
remove 
remove 
remove 
remove 



rf (Sid) 
rf (Sid) 
.pf (Sid) 
.pe(SId) 
rf (Sid) . 
rf (Sid) . 
.pf (Sid) . 
.pe(SId) . 
rf (Sid) 
_rf (Sid) 



d3_rf _suspended(V,D! ,D 2 ,ldi ,ld 2 ,SId) <=> nonvarddt) I true. 
d3_rf _suspended(V,Di ,D 2 ,Idi ,Id 2 ,SId) <=> nonvar(Id 2 ) I true. 



5.3 Program- Independent Part: the Scheduler 

The scheduler implements the schedule_rf /2, remove_rf/l, schedule_pf /3, 
remove_pf/l, schedule_pe/2 and remove_pe/l predicates. It furthermore imple- 
ments the execute/0 predicate which retrieves and executes the highest priority 
scheduled task. This task either is the firing of a rule instance by asserting a fire/1 
constraint, or the matching of a prefix firing with a prefix extension by asserting a 
match/2 constraint. The execute/0 predicate recursively calls itself until no more 
tasks are scheduled. It is first called after processing the initial goal. 

For the implementation of the scheduler, we use a variant of the scheduling al- 
gorithm presented in (|De Koninck 2007)) . This algorithm can be used to maintain 
which prefix firings are still to match with which prefix extensions. It is roughly 
based on the W(r, t) data structures used in ([Ganzinge r and McAllester 2002[ ). Such 
a data structure consists of a series (implemented as a linear linked list) of prefix 
blocks, which are sets of prefix firings and (apart from the last one) are associated 
with a prefix extension. 

The semantics of the W(r, t) data structure is that the prefix firings of a given 
prefix block are still to match with the prefix extension associated to it, as well 
as with all prefix extensions associated to subsequent prefix blocks. The last prefix 
block has no associated prefix extension, and represents those prefix firings that have 
been matched with all prefix extensions and hence are passive (or completed using 
the terminology of (Ganzinger and McAlleste r 2002[ )). Whenever a prefix extension 



is deleted, its prefix block is merged with the next prefix block. 

There is one W(r, t) data structure for each prefix length of each rule and for 
each combination of arguments shared between a prefix firing and prefix extension. 
Each prefix block is represented as a (local) priority queue whose items are the 
block's prefix firing. The highest priority item of each prefix block, together with 
its associated prefix extension, is also represented in a global priority queue. This 
prefix block representative is updated whenever the highest priority prefix firing 
of the prefix block is removed, a new prefix firing has the highest priority, or the 
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associated prefix extension is removed. The global priority queue furthermore con- 
tains a representative for each rule firing. The reason for using two layers of priority 
queues is to reduce the amount of work needed when the prefix firings of a prefix 
block all become passive due to a prefix extension removal. It is the global priority 
queue that determines the next task to perform, i.e., matching a prefix firing with 
a prefix extension, or firing a rule instance. 

In the context of CHR rp , built-in constraint (in particular equality constraints) on 
the arguments shared between a prefix firing and extension, may require merging of 
W(r, t) data structures. The data structure of (|De Ko ninck 2007) supports sched- 
ule merges in quasi constant time. The most notable difference with the W(r, i) 
data structure of ([Ganzinge r and McAllester 2002[ ) is that the prefix blocks form a 
circular linked list. Using this representation, merging schedules consists of cross- 
linking the circular lists and reactivating the prefix firings that were passive before 
the merge. Special care is taken to prevent both that a prefix firing is being matched 
with the same prefix extension more than once, and that a prefix firing 'misses' a 
prefix extension. 

One consequence of using a circular linked list instead of a linear one to represent 
the prefix blocks, is that it is unclear (or more precisely, too expensive to decide) 
which prefix firings become passive whenever a prefix extension is deleted. There- 
fore, this decision is postponed until the scheduler tries to match the prefix firing 
with the next prefix extension in line. For complexity reasons, it is important that all 
prefix firings that have simultaneously been reactivated, and have not been matched 
with a prefix extension since this reactivation, are simultaneously made passive in 
time independent of the number of prefix firings affected. In (De Kon inck 2007[) . 
a so-called element schedule based on a stack is proposed to supports this. In our 
context, we need an element schedule that is based on priority queues. It works as 
follows. 

We use three types of priority queues. The first one is a single global priority 
queue which contains an item for each rule firing, for each active prefix firings that 
either has not been passive before or has been matched with at least one prefix 
extension since its last activation, and finally, for each set of prefix firings that have 
been simultaneously activated and have not been matches with a prefix extension 
since. A second type of priority queues is called a local queue and represents the 
above mentioned sets of prefix firings. Finally, the third type of queues is the passive 
queue which contains an item for each passive (completed) prefix firing. There is 
one passive queue for each schedule. Essentially, we again use two layers of priority 
queues. Whenever a set of previously passive prefix firings, represented as a passive 
priority queue, is reactivated because of a new prefix extension or because of a 
schedule merge, this passive priority queue becomes a local priority queue and has 
a representative inserted into the global priority queue. If such a representative 
is the highest priority item in the global priority queue, and an execute/0 call 
is made, then the highest priority prefix firing of the represented local priority is 
removed and dealt with as an ordinary prefix firing. The representatives of local 
priority queues are updated (and potentially removed) similarly to how this is done 
in the W(r, t) data structure of ( |Ganzinger and M cAlles ter 2002[ ). 



34 



Leslie De Koninck 



global queue 




prefix block 
{PF l ,PF 2 ,PF 3 ] 
rule firing 



PE 



local queue 



{^4-^5 
passive queue 

^6 

PF n 



PE^ 



Figure 1. Example schedule with global, local and passive priority queues 
Example 8 

Figure[T]illustrates the prefix blocks, the different types of priority queues, and their 
contents. The global queue, which is shared by all schedules, contains the rule firings 
RF\ and RF 2 , the prefix firings PFi, PF4, PF 5 and PF$ (the last of which belongs 
to another schedule), and the local queue representative LQ 1 . The represented local 
queue contains the prefix firings PF2 and PF3 which are by definition also in the 
same prefix block. The schedule's passive queue contains the prefix firings PF 6 and 
PF-j. The schedule has two prefix blocks, which are associated with respectively 
the prefix extensions PE\ and PE-i. 

Using our approach, the cost of deleting items from the global priority queue can 
be amortized to one of the following events: a new rule firing, a new prefix firing, a 
new prefix extension (for each representative of a local priority queue), or a match 
between a prefix firing and a prefix extension (which corresponds to either a new 
larger prefix firing, or a rule firing). 

In (Ganzinge r and McAllester 2002[ ), retrieving the schedule for a given prefix 



firing or prefix extension is done by hashing. In our approach, we use a variant 
of hashing, which we call non-ground hashing and which consists of first replacing 
all variables by a unique identifier, and then using the resulting (ground) term for 
hashing. Unifications may require rehashing the affected keys and potentially also 
the merging of schedules. 



5.4 Priority Queues 

A priority queue or heap is a data structure that contains a set of prioritized items 
and supports the following operations: inserting and removing an item, finding a 
highest priority item and merging with another queue. The implementation proposal 
in flGanzinger and M cAllest er 2002[ ) suggests the use of two types of priority queues, 
one for the fixed priorities, where each of the supported operations takes constant 
time, and Fibonacci heaps for the dynamic priorities. 

Fibonacci heaps ( |Fredman and Tarjan 1987) are a type of priority queue that of- 



Logical Algorithms meets Constraint Handling Rules 



35 



for 0(1) amortized time insertion, heap merging and finding a highest priority item, 
and 0(log n) amortized time item removal with n the number of items in the queue. 
It is suggested in ( Ganzinger and McAllester 2002) that by using only one node per 
priority, using linked lists to represent the items that share this priority, the item 
removal cost can be reduced to O(logiV) with N the number of distinct priorities. 
However, this increases the cost of heap merging from 0(1) for a single merge oper- 
ation to a total cost of 0(n log N) for merging heaps when there are n items in total 
and N distinct priorities (as is shown in an Appendix of (Dc Koninck et al. 2007aj) ). 
A CHR implementation of Fibonacci heaps is described in ( |Sneyers et al. 2006a[ ). 
It can easily be extended to support multiple heaps that can be merged and to use 
only one node for each distinct priority per heap. 



6 A New Meta- Complexity Result for CHR rp 

In this section, we give a new meta-complexity result for CHR rp . It extends the 
result via translation to Logical Algorithms, by also supporting built-in constraints 
and non-ground CHR constraints. We make the following assumptions: 

• Hash tables support 0(1) insertion, removal, and retrieval of all elements that 
match a given (ground) key. 

• The inverse of the Ackermann function (a(n)) is a constant. 



The first assumption is also made in (Ganzinger and McAllester 2002) and holds 



on average as long as the hash function is good enough. The second assumption is 
needed for our scheduling data structure (|De Koninck 2007)) which internally makes 
use of the union-find algorithm. The inverse of the Ackermann function is positive 
and less than 5 for all practical purposes. 

We start by looking at the complexity of the different operations supported by 
our scheduler. 

Lemma 6 (Scheduler Costs) 

Let N be the number of distinct priorities, and assume that a priority queue merge 
takes some abstract time T, then the schedule operations have the following amor- 
tized cost: 

• 0(1) and 0(logiV) for each schedule_pf /3, remove_pf /l, remove_pe/l, 
remove_rf/l and execute/0 operation involving respectively a static and 
dynamic priority rule 

• 0(T + 1) and 0(T + logiV) for each schedule_pe/2 operation involving 
respectively a static and dynamic priority rule 

• 0(1) for each schedule merge and schedule_rf /2 operation 

Proof 

We only consider the costs related to the priority queue operations. The other costs 
are shown to be (quasi) constant in (|De Koninck 2007)) . We now look at the different 
operations in detail: 
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A schedule_pf /3 call consists of inserting the new prefix firing into the global 
priority queue. We also account to this event, the cost of making the new prefix 
instance passive the first time. That operation consists of a removal from the global 
priority queue and an insertion into the schedule's passive queue. The total cost is 
0(1) if the element has a static priority, and 0(log N) if it has a dynamic priority. 
A schedule_pe/2 call requires the insertion of a new representative for the local 
priority queue of reactivated prefix firings, into the global priority queue. We also 
take into account here, the cost of making all the reactivated prefix firings passive 
that have not been matched with a prefix extension since the reactivation. That 
operation consists of removing the representative and merging the local priority 
queue with the schedule's passive queue. The cost is 0(T + 1) for a static priority 
rule and 0(T + log TV) time for a dynamic priority one. 

A schedule_rf /2 call requires an insertion into the global priority queue which 
takes 0(1) time. 

A remove_pf/l call consists of deleting the prefix firing from the global priority 
queue, from a local priority queue or from a passive queue. A deletion from a local 
queue may moreover require an update of the global queue (removal and insertion). 
In total, this takes 0(1) time for a static priority rule and (log TV) time for a 
dynamic priority rule. 

A remove_pe/l call does not require any priority queue operations, and so the cost 
is 0(1). 

A remove_rf/l call requires a removal from the global priority queue which takes 
0(1) time if it involves a static priority rule and 0(log/V) time if it involves a 
dynamic priority rule. 

An execute/0 call requires retrieval and potential removal (if the retrieved item 
corresponds to a rule firing, or to a prefix firing that becomes passive) of the highest 
priority item in the global priority queue. If the retrieved item represents a prefix 
firing or set of prefix firings that need to be made passive, the cost of this operation 
is already accounted for by a previous schedule_pf /3 or schedule_pe/2 operation. 
In such case, we call the execute/0 call unsuccessful. An unsuccessful execute/0 
call is followed by another execute/0 call until either such a call is successful, or 
the global priority queue is empty and thus a final state is reached. The cost of 
all unsuccessful execute/0 calls can be amortized to previous events. If in case 
of a successful execute/0 call, the item retrieved from the global priority queue 
corresponds to the representative of a local priority queue, the operation requires a 
removal of the highest priority item (prefix firing) from this local queue, an insertion 
of the prefix firing into the global priority queue, and potentially the insertion of a 
new representative for the local queue into the global queue. The cost of a successful 
execute/0 call therefore equals 0(1) if it involves a static priority rule and 0(log N) 
otherwise. 

A schedule merge requires the reactivation of the passive prefix firings of the merged 
schedules. The cost analysis is similar to that of a schedule_pe/2 call. Moreover, 
each schedule merge can be accounted for by at least one schedule_pe/2 call as 
the resulting schedule contains at least one prefix extension more than each of the 
original schedules, and so the number of schedule merges is bounded by the number 
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of prefix extensions. Therefore, the cost of a single schedule merge can be considered 
constant. 

□ 

In the above lemma, we have made abstraction of the cost of priority queue merge 
operations. Such merges take place when the prefix firings in a local priority queue 
all become passive. In such an event, the local priority queue is merged with the 
schedule's passive queue. It is easy to see that the cost of merging priority queues 
for static priorities takes constant time per merge operation. In Scction[53]a bound 
is given on the total cost of merging Fibonacci heaps with one node per distinct 
priority, given the number of items ever inserted into the heaps. The following 
lemma makes use of this result. 

Lemma 7 (Fibonacci Heap Merging Cost) 

The total cost of Fibonacci heap merges is 0((Pd + Ad) ■ logiV) where Pd is the 
number of strong prefix firings of dynamic priority rules, Ad is the number of 
constraints that may participate in a dynamic priority rule instance, and N is the 
number of distinct rule priorities. 

Proof 

We count the number of items ever inserted into the local and passive Fibonacci 
heaps, and then apply the result of Section r5.4l A local priority queue basically is the 
same as a passive priority queue in which items are no longer inserted. Therefore, 
a merge between a local queue and a passive queue can be seen as a special case of 
a merge between two passive queues and so we only need to consider these passive 
priority queues. Each item inserted in such a queue is either a prefix firing that has 
never been passive before, or a prefix firing that has been matched with a prefix 
extension at least once since its last activation. The total number of these items is 
0(Pd + Ad) because each prefix firing that has been matched with a prefix extension 
is by definition a strong prefix firing, and each new prefix firing either results from 
matching a (smaller) strong prefix firing and extension and hence corresponds to 
a (potentially suspended) strong prefix firing, or consists of a single head in which 
case it corresponds to a constraint assertion. Now given the number of items ever 
inserted into the passive priority queues, the total cost of merging Fibonacci heaps 
hence is 0((P d + A d )-logiV)). □ 

We are now ready to formulate the new meta-complexity theorem. 
Theorem 6 

Let A s and Ad be the number of assertions of constraints with an occurrence in 
respectively a static and dynamic priority rule. Let P s and Pd be the number of 
strong prefix firings of respectively static and dynamic priority rules. The time 
complexity of a CHR rp program executed using our implementation is 

+ C a B sk ) ■ (A s + P s + {A d + P d ) ■ logJV) + B ■ Cjf" ■ (K + C a B sk ■ S)) 

where N is the number of distinct priorities, C B k is the cost of evaluating a built- 
in ask constraint, C B U is the cost of solving a built-in tell constraint, and B is 
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the number of built-in tell constraints asserted in rule bodies; K is the maximum 
number of distinct combinations (keys) of arguments shared between prefix firings 
and extensions in which any given variable occurs, and S is the maximum number of 
suspended strong prefix firings (i.e., those that are followed by a non-trivial guard) 
and suspended instances of constraint occurrences (i.e., whose arguments are not 
mutually distinct variables) in which any given variable occurs. 

Proof 

Each new CHR constraint causes the creation of constraint occurrences which are 
converted into RETE memory constraints as soon as the implicit guard on the 
constraint arguments is entailed (i.e., the constraint matches the head in ques- 
tion). These RETE memory constraints are scheduled using schedule_pf /3 for 
the single-headed prefix firings, schedule_rf /2 for the single-headed rule firings, 
and schedule_pe/2 for the prefix extensions. The total cost of these operations, 
including the cost of priority queue merges (for the schedule_pe/2 calls), equals 
+ C b asfc ) • (A a + (A d + P d ) log iV)). Each constraint deletion causes the deletion 
of those RETE memory constraints in which the deleted constraint participated. 
The total cost related to deletion therefore is 0(A S + P s + (Ad + Pd) logiV). Each 
prefix firing is inserted into its schedule at most once and hence it can also be 
removed from this schedule only once (when one of its constituent constraints is 
removed). Those prefix firings that consist of at least two heads, correspond to a 
strong prefix firing as they are generated at a priority higher or equal to that of the 
highest priority rule firing. Thus, using Lemma[6]and including the cost of checking 
the relevant parts of the guard, the cost for inserting (and deleting) these prefix 
firings is + C£ sk ) • (P s + P d \ogN)). 

A built-in tell constraint is processed as follows. The keys used to identify the 
schedules and that are affected by the built-in constraint, are rehashed. If the built- 
in constraint causes two or more schedules to have the same key, these schedules are 
merged. The cost of rehashing is proportional to the number of affected keys and the 
cost of a schedule merge is constant by Lemma [6l A built-in constraint moreover 
requires the reactivation of the suspended prefix firings and rule firings, as well 
as those constraint occurrences for which it is not decided whether they match 
with the corresponding head or not. The reactivated prefix and rule firings have 
their guard checked and are potentially scheduled as regular (non-suspended) prefix 
and rule firings. The reactivated constraint occurrences also have their (implicit) 
guard checked, and are potentially scheduled as single-headed prefix firings, single- 
headed rule firings, or prefix extensions. The cost of the scheduling operations was 
already taken into account above. The remaining cost per built-in tell constraint is 
0{C l b eU ■(K + Cg sk -S)). □ 

The values of S and K might be difficult to determine in practice, but we can 
use an upper bound of 0(A S + Ad + P s + Pd) for both parameters. The reasoning 
for S is that the number of suspended prefix firings is smaller than the number of 
prefix firings and the number of suspended constraint occurrences is smaller than 
the number of assertions times the number of rule heads in the program. For K, 
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we have that the number of keys shared between prefix firings and extensions is 
limited by the total number of prefix firings and extensions. We have used the cost 
of solving a built-in tell constraint as an upper bound on the number of variables 
that are affected. 

The meta-complexity theorem also applies to (regular) CHR programs, which 
can be seen as a special case of CHR rp programs in which all rules have the same 
(static) priority; see Theorem 3 of (|De Koninck et al. 2007b|) for more details. 

6. 1 Examples 

We illustrate the meta-complexity theorem on some examples, and compare with 
the results obtained by using the approach of (Fruhwirth 2002b). 

Example 9 (Less-or-Equal) 

The less-or-equal (leq) program is classic CHR example. It implements a less- 
than-or-equal-to constraint by eventually translating it into equality constraints. A 
CHR rp implementation of the program consists of the following rules. 

1 :: idempotence @ leq(X,Y) \ leq(X,Y) <=> true. 

2 :: reflexivity @ leq(X,X) <=> true. 

2 :: antisymmetry @ leq(X,Y), leq(Y,X) <=> X = Y. 

3 :: transitivity leq(X.Y), leq(Y.Z) ==> leq(X,Z). 

Given an initial goal consisting of n leq/2 constraints where the arguments are 
taken from a set of n distinct variables, we derive the following values for the 
parameters: 

• P s : the number of strong prefix firings is 0(n 2 ) for the idempotence rule, 0(n) 
for the reflexivity rule, 0{n 2 ) for the antisymmetry rule, and 0(n 3 ) for 
the transitivity rule. These numbers are found by looking at the degrees of 
freedom for each constraint occurrence, based on the domain of the arguments, 
and given those arguments that are already fixed by the left-most heads. For 
example for the transitivity rule, we know that there are 0(n 2 ) constraints 
matching the first head, and 0(n) constraints matching the second head, 
given the first. Our reasoning is based on the fact that at priority 2 and lower 
(numerically larger), all leq/2 constraints have set semantics because of the 
idempotence rule. 

• A s : the number of leq/2 constraints asserted is 0(n 3 ) (by the transitivity 
rule) . 

• B: the number of built-in constraints is bounded by the number of rule firings 
of the antisymmetry rule, and hence is 0(n 2 ). 

• K: the schedule keys are the combination of X and Y in both the antisymmetry 
rule and the idempotence rule, and Y in the transitivity rule. There are 
at most 0(n) different keys in which any given variable occurs. 

• S: for any variable, and in a state in which a built-in constraint can be as- 
serted, there are up to 0(n) suspended instances of the leq/2 occurrence in 
the reflexivity rule. There can be no suspended prefix or rule firings. 
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• and C^ eU : the cost of evaluating a built-in ask constraint and the cost 

of solving a built-in tell constraint is constant (at least for the given query 
pattern). 

Filling in these parameters in the formula given by Theorem [6] gives us a worst case 
time complexity of 

0{{l + 1) • (n 3 + n 3 + (0 + 0) • log 3) + n 2 ■ 1 • (n + 1 ■ n)) = 0{n 3 ) 

This corresponds to the actual worst-case complexity for an initial goal of the form 

{leq(X 1 ,X 2 ),...,leq(X n - 1 ,X n ),leq(X n ,X 1 )} 

The approach of (|Fruhwirth 2002b|) does not apply since the transitivity rule is 
a propagation rule and hence no suitable ranking function can be found. 



Example 10 [Merge Sort) 

Consider the CHR rp implementation of the merge sort algorithm, first given in 
Example [5] (Section 2]) and repeated here for easy reference. 



1 : 


: msl ( 


3 arrow (X, A) \ arrow (X,B) <=> A < B 


arrow(A,B) . 


2 : 


: ms2 ( 


5 merge (N, A) , merge (N,B) <=> A < B 


merge(2*N+l,A) , arrow (A, B) . 


3 : 


: ms3 < 


5 number(X) <=> merge(O.X). 





We show that the total runtime of the algorithm is O(nlogn) given an initial goal 
consisting of n number/1 constraints. 

No new number/1 constraints are ever asserted. Rule ms3 converts one number/1 
constraint into one merge/2 constraint each time it fires. The number of (strong) 
prefix firings for rule ms3 hence is 0{n). Rule ms2 decreases the number of merge/2 
constraints by one and so it can fire n — 1 times. In any state, there are at most 
two merge/2 constraints with the same first argument. This invariant holds in the 
initial state because there are no merge/2 constraints in the initial goal and rule 
ms2 can fire after each new merge/2 constraint assertion, enforcing the invariant. 
Because of the invariant, the number of prefix firings for rule ms2 is limited to 0(n). 

Using similar reasoning it holds that in any state, there are at most two arrow/2 
constraints in the store with the same first argument. Now we define that in a 
given state, two numbers X\ and X m are connected by a chain of length m — 1 
if the following constraints are in the store: arrow(Xi,X2), arrow (X2 ,^"3) , . . . , 
arrow (X m -i,X m ) . At priority 2 it holds that for each merge(N ,X) constraint 
in the store, the maximal length of a chain starting in X is N. Indeed, this holds 
for the initial merge (0,_) constraints and if it holds for merge (N constraints, 
it also holds for merge (2 • N + 1,_) constraints, because when such a constraint 
is asserted, two chains of length N are linked with an extra arrow/2 constraint 
and merged by up to 2 • N firings of rule msl. Two merge (iV,_) constraints are 
combined into a merge (2 • TV + 1,_) constraint, so the n merge (0,_) constraints 
asserted by rule ms3 are replaced by n/2 merge (1 , _) constraints, which in turn are 
combined into n/4 merge (3, _) constraints and so on until finally 1 merge (rt — 1 ,_) 
constraint remains. The sum of all N in these merge (N , _) constraints is 0(n log n). 
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Rule msl fires O(N) times after every new merge (N constraint assertion and 
because there are at most two arrow/3 constraints with the same first argument, 
there are C(nlogn) strong prefix firings of rule msl. 

In conclusion, for an initial goal consisting of n number/1 constraints, there are 
0(n logn) strong prefix firings for rule msl, 0(n) for rule ms2 and 0(n) for rule ms3. 
Using the meta-complexity theorem, which simplifies to the one for Logical Algo- 
rithms because there are no built-in tell constraints, the total runtime is O(nlogn), 
which is also a tight complexity bound. We now compare this result with the result 
found by using the meta-complexity theorem of (jFruhwirth 20 02b). 

Using a similar analysis as above, we can derive that D — O(nlogn) and c max — 
0(n) where n is the number of number/ 1 constraints in the query. Note that in 
Theorem 4.2 of (jFriihwirth 2002bp . a worst case upper bound of c max — 0(c + D) 
is used, with c the number of constraints in the query, which becomes c max = 
O(nlogn) in this example. The bound we use is tight, i.e., c max — Q(n). The cost 
of head matching (Oji r ), guard checking (C?G r )j adding built-in constraints (Oc r ), 
and adding and removing CHR constraints (0_e r ), can all be assumed constant. 
The number of heads n r of a rule r G P is at most 2. Filling in these numbers, we 
derive a total worst case complexity of 0(n 3 logn), which is clearly suboptimal. 



Example 11 (Dijkstra's Shortest Path) 

A Logical Algorithms implementation of Dijkstra's shortest path algorithm is given 



in ( Ganzinger and McAllcster 2002 ) and in Example [2j A very similar implemen- 



tation in CHR rp is given in (Dc Koninck ct al. 2007b) and shown below. 



1 
1 

D + 2 



dl @ source(V) ==> dist(V,0). 

d2 @ dist(V,Di) \ dist(V,D 2 ) <=> Di < D 2 I true. 
d3 @ dist(V,D), e(V,C,U) ==> dist(U,D+C). 



Given a goal consisting of one source/1 constraint and e e/3 constraints, the 
runtime complexity of this implementation is O(eloge). The analysis is essen- 
tially the same as the one for the Logical Algorithms implementation as given 
in flGanzinger and McAl lcster 2002]); see also Example [2l 



6.2 Comparison with the Logical Algorithms meta-complexity result 

In (|De Koninck et al. 2007ap . we have presented a direct implementation of the 
Logical Algorithms language into CHR that satisfies the complexity requirements 
needed for the Logical Algorithms meta-complexity result to hold. In this subsec- 
tion, we show that this implementation has become somewhat obsolete because we 
can achieve the same result by combining the translation from Logical Algorithms 
to CHR rp of Section [3l with the CHR rp implementation presented in Section [5] We 
assume here that the comparison antecedents in Logical Algorithms programs are 
scheduled after the corresponding user-defined antecedents in the translation, and 
that the guards on the mode indicators (these have the form N ^ p) are scheduled 
right after the head to which they apply. 
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Theorem 7 

The time complexity of Logical Algorithms programs executed by first translating 
them into CHR rp programs using the translation schema of Section [21 and then 
executing the resulting CHR rp program using the implementation of Section [5J is 
O(\o- \+P s + (P d +A d )-\ogN) with So, P s , P d , A d and N as defined in Scction l2"XTl 

Proof 

The translation of a Logical Algorithms program P consists of two parts as defined 
in Section [31 The first part, denoted by Tg/ D (P), contains for each user-defined 
predicate a/n the following rules: 

1 :: a r (X, M) \ a(X) ^> M ^ n true 
1 :: a r (X,n),a(X) ^> a r (X,b) 
2 :: a(X) a r (X,p) 

1 :: a r (X,M) \ del(a(X)) ^> M^p | true 
1 :: a r (X,p),del(a(X)) ^=4> a r (X,b) 
2 :: del(a(X)) a r (X,n) 

It is easy to see that for an initial goal containing no constraints of the form 
a r {X,M) and since these are the only rules that assert such a constraint, in any 
state it holds that if a r (X,Mi)#ii and a r (X ,M-i)^ii are in the CHR constraint 
store, then i\ — i% and M\ = Mi. This implies that the number of strong prefix 
firings for these rules is bounded by the number of assertions of a(X) or del(a(X)). 

The second part of the translation, denoted by Tr(P), contains for each Logical 
Algorithms rule 

r@p:A 1 ,...,A n ^C 

a set of rules 

p + 2::r p @H =^ fli,<? 2 |C' 
as shown in the translation schema of Section 13.1.21 Amongst these rules is one, 
say r p i , with a maximal number of heads, namely as many as there are user-defined 
antecedents in Ax, ... , A n . Because the (implicit and explicit) guards on the mode 
indicators of the head constraints are scheduled as soon as they are decidable, and 
because the comparisons are scheduled at corresponding places, it is easy to see 
that the number of strong prefix firings of rule r p i is the same as the number of 
strong prefix firings of Logical Algorithms rule r. The other r p rules are restricted 
versions of r p i and therefore have at most as many strong prefix firings as r p i . 

The assertions with occurrences in dynamic priority rules are of the form a r {X, _). 
The set and deletion semantics rules ensure that the number of these assertions is 
the same in the original program and in its translation. Finally, we note that the 
number of assertions with occurrences in a static priority rule, A s , is bounded by the 
number of assertions in the initial goal | cr 1 plus the number of rule firings times the 
maximal number of body literals in any rule. Therefore, A s = 0(|<7o|+i :, s+-Pd)- Now 
using our new meta-complexity result for CHR rp (Theorem [6]) , we derive that the 
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total runtime complexity of the translated program is O(\ao\+ P s + (Pd+ Ad) -log N) . 
□ 

6.3 Comparison with the "As Time Goes By" approach 

In Section [2.3.3l we already briefly compared the Logical Algorithms meta-complexity 
theorem with the theorem given by Fruhwirth in (Fruhwirth 2002b). In this sub- 
section, we make the comparison complete by also considering built-in constraints, 
using the new meta-complexity theorem presented in Section [6l 

Let there be given a CHR rp program P in which each rule has the same (static) 
priority. Theorem 3 in (|De Koninck et al . 2007b) states that such a CHR rp pro- 
gram and its corresponding CHR program (which is found by removing the rule 
priorities) have the same derivations. Therefore, such programs are suitable for com- 
paring the result of (jFriihwirth 2002b]) with the result of Theorem [6] in Section [6] 
In Section 12.3.31 we have already shown that the number of strong prefix firings is 
O (D ■ J2 reP where D is the derivation length (i.e., the number of rule fir- 

ings), and c rnax is the maximal number of CHR constraints in the store in any state. 
The number of constraint assertions is 0(c max + D). If we assume that the initial 
goal does not contain any built-in constraints (as is done in (Fru hwirth 200 2b)). 
then the number of built-in constraints is 0(D). The number of suspended prefix 
firings is bounded by O (J2r£P c max) m an y state and the number of suspended as- 
sertions by 0(c max )- Now, filling in these parameters in the CHR rp meta-complexity 
result gives us that the total runtime complexity is 

OUl + O c )-DY,{c^ ax -0 Gr )\ (3) 

V rGP / 

where Oc = X)rep(^cv)- This formula strongly resembles the result of (jFriihwirth 2 002b) 
which, assuming the cost of head matching Or t and adding and removing CHR 
constraints Ob t is constant, equals 

C^ECCax-O^+Oojj (4) 

The difference lies in how built-in tell constraints are dealt with. In our CHR lp 
implementation, as well as in any CHR implementation based on the refined opera- 
tional semantics of CHR, a built-in tell constraint causes the constraints or matches 
whose variables are affected, to be reconsidered!! Because each individual (atomic) 
built-in constraint is dealt with separately, this may cost more in total than the 
naive approach taken in (jFriihwirth 2002b|) in which after each rule firing, all con- 
straints or matches are reconsidered once. So, while in certain rather exceptional 
cases, a naive approach to dealing with built-in tell constraints might in fact be bet- 
ter than the usual approach of selective reactivation (as can be seen by comparing 



5 Which constraints are reactivated depends on the wake-up policy used for the Solve transition, 
see also l |Schrijve"rs" '2005] Section 5.4.2). 
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Formulas ([3]) and ||3J)), in general we expect the latter approach to be an improve- 
ment over the naive one. Moreover, in these exceptional cases, the meta-complcxity 
theorem of (jFriihwirth 2002b)) does not apply to optimized CHR implementations 
like the K.U.Leuven CHR system, i.e., in these cases it does not overestimate the 
actual worst case time complexity. 

Noteworthy is that the approach of (jpriihwirth 2002b| only considers simplifi- 
cation (and implicitly also simpagation) rules. This restriction is related to the 
termination analysis which is used to find an upper bound on the number of rule 
applications. However, if we can find such an upper bound by other means, also 
propagation rules can be supported. For instance, the termination analysis pre- 
sented in ( |Pilozzi and D c Schrcyc 2008]) can be used for this purpose. 



7 Conclusions 

In this paper, we have investigated the relationship between the Logical Algorithms 
language and Constraint Handling Rules. We have presented an elegant translation 
schema from Logical Algorithms to CHR rp : CHR extended with user-definable rule 
priorities. The original program and its translation are shown to be essentially 
weakly bisimilar. However, our current CHR rp system (|De Koninck et al. 2 008) 
does not give the complexity guarantees needed for the Logical Algorithms meta- 
complexity theorem to hold via this translation. 

As a first step towards applying the Logical Algorithms meta-complexity result 
to CHR rp programs, we have shown how a subclass of CHR rp can be translated 
into Logical Algorithms. By using this translation, we can directly apply the meta- 
complexity theorem for Logical Algorithms to the translated CHR rp programs. A 
drawback is that the CHR rp programs that can be translated this way, are restricted 
to those that do not make use of an underlying constraint solver. 

In order to remedy both the limitation that the translation from Logical Algo- 
rithms to CHR rp does not exhibit the required complexity when executing trans- 
lated Logical Algorithms programs using our CHR rp system, and the restriction 
of those CHR rp programs that can be translated to Logical Algorithms and hence 
to which the Logical Algorithms meta-complexity result can be applied, we have 
proposed a new implementation for the complete CHR rp language that gives strong 
complexity guarantees. The implementation is based on the high-level implementa- 



tion proposal of ( Ganzinger and McAllester 2002 ) as well as on the scheduling data 



structure of (|De Koninck 2007|) . and consists of the compilation of CHR rp rules into 
(regular) CHR rules, combined with a scheduler that controls the execution. The 
implementation supports a new and accurate meta-complexity theorem for CHR rp . 
When combining the translation from Logical Algorithms to CHR rp with the new 
implementation, the new meta-complexity theorem implies the Logical Algorithms 
meta-complexity result. Moreover, it is shown that in general - apart from some 
rather exceptional cases, see Section [6731 - the new theorem is at least as accurate 
as the meta-complexity result for CHR given by Friihwirth in (Fruhwir th 2002b[) . 
This is illustrated on two non-trivial examples, one of which contains both built- 
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in constraints and propagation rules and therefore cannot be analyzed using the 
Logical Algorithms approach or Friihwirth's result. 



7.1 Related Work 

The time complexity of programs is in general expressed in terms of the number of 
elementary operations, e.g., the number of logical inferences in Prolog, function ap- 
plications in a functional programming language, or rule applications in a language 
such as CHR. However, while in most languages, these elementary operations all 
take constant time, this is not the case in a language like CHR where each rule 
application results from a complex matching phase. 

In this work, we have made a mapping from the number of elementary oper- 
ations (like prefix and rule firings or constraint assertions) to time complexity. 
To the best of our knowledge, and apart from the results in ([McAllester 1999[ 
|Ganzinger and McAllester 2001||Ganzinger and McAllester 2002[ ) and (|Fruhwirth 2002al 
Friihwirth 2002b]), there is no other work with a similar goal. There are many 
other formalisms though in which elementary operations take more than constant 
time. One such formalism is term rewriting, as implemented by the Maude system 
IjClavel et al. 1999j) or the ACD term rewriting language (jDuck et al. 2006}) . It is 
known that AC matching, which is used by most of these languages, is NP-complete. 
Another formalism is that of production rule systems like Drools ([Proctor et al. 2 007) 
or Jess (Friedman-Hill 2007). Production rules are in many ways similar to Con- 
straint Handling Rules. However unlike CHR, these systems are not often used as 
general purpose programming language, and therefore, algorithmic complexity has 
never been much of a concern. More work exists on the derivation of the number of 
elementary operations. In the context of CHR, this mostly concerns the number of 
rule firings, which is often derived as part of termination analysis fFriih wirth 2000bl 
IPilozzi et al. 20071 IVoets et al. 2007|) . 

Another related topic is that of space complexity, an issue that is not dealt with 
in this paper. In the context of CHR, the memory reuse techniques developed in 



(Sneyers et al. 2006b) are crucial to achieve optimal space complexity as is shown in 
(Sneyers et al. 2008). The latter also introduces a space complexity meta-theorem 
for CHR, stating that the space complexity is 0(D + p) where D is the derivation 
length and p is the number of propagation rule firings (which takes into account 
the size of the propagation history). 



7.2 Future Work 

For a previous version of this paper (Dc Koninck et al. 2007a), we have made an 
actual implementation for the Logical Algorithms language in CHR. This imple- 
mentation satisfies the complexity requirements needed for the Logical Algorithms 
meta-complexity theorem to hold, when executed using the K.U.Leuven CHR sys- 
tem on top of SWI-Prolog. However, the very large constant factors and the high 
memory consumption makes that the system is not very useful in practice. Cur- 
rently, we have no running version of the alternative implementation for CHR rp 
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presented in Section [5] The reason is that this implementation proposal is based 
on a similar approach as the Logical Algorithms one, and in particular the more 
complicated scheduler is expected to be slow in practice. However, we do intend 
to investigate the advantages and disadvantages of a lazy RETE based matching 
algorithm for CHR( rp ) compared to the LEAPS style matching that is currently 
used by almost all systems. A simplified version of the scheduling data structure 
of (|De Koninck 2007j) which would offer less complexity guarantees, but might be 
faster in the average case, could be used for this purpose. 

We have already mentioned in the related work discussion that a space complex- 
ity result for our alternative implementation is currently lacking. The RETE style 
matching we used is in general far from optimal as far as memory usage is con- 
cerned, in particular compared to LEAPS style matching as is used by most CHR 
systems. However, in the CHR context, built-in constraints may require maintain- 
ing a propagation history which in the worst case requires as much memory as the 
alpha and beta memories in RETE matching. Therefore, it would be interesting to 
more formally compare both styles of matching in terms of memory consumption 
in the context of CHR. 
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